On Tue, Feb 16, 2016 at 12:51 PM, <[email protected]> wrote: > Thank again Jakob. > >> Of course you can also use a debugger of your choice, interrupt the >> program when it's in the state you want to inspect, and start disassembling >> whatever you're interested in. >> > Actually, I can't use print function in gdb with d8. I compile v8 in debug > mode. > What should I do to provide debug symbols in full-codegen in other v8 > parts? >
Works for me. I don't know what the problem might be, sorry. > On Tuesday, February 16, 2016 at 3:50:01 PM UTC+6, Jakob Kummerow wrote: >> >> On Tue, Feb 16, 2016 at 10:38 AM, <[email protected]> wrote: >> >>> 1) 0x36c28f53eecf 47 e8cc92fdff call 0x36c28f5181a0 ;; code: >>> contextual, LOAD_IC, GENERIC >>> Who does generate this stub? Full-codegen? >>> >> >> No, the IC system. You can start reading in LoadIC::Load in src/ic/ic.cc >> and trace your way to the various HandlerCompilers, but be warned: there's >> a lot of complexity there. >> >> >>> 2) As I undertood the effictive code is placed in IC stub? >>> >> >> Depends on what you mean by "effective code". Originally you said you >> wanted to understand full codegen. Stubs are not part of full codegen. >> >> >>> If this is true then where can I see the stub's code? >>> >> >> --print-code-stubs. However, for this specific example, you won't see a >> stub there, because loading properties from numbers is handled specially. >> >> Of course you can also use a debugger of your choice, interrupt the >> program when it's in the state you want to inspect, and start disassembling >> whatever you're interested in. >> >> >>> On Tuesday, February 16, 2016 at 3:18:07 PM UTC+6, Jakob Kummerow wrote: >>> >>>> On Tue, Feb 16, 2016 at 10:08 AM, <[email protected]> wrote: >>>> >>>>> Thank Jakob. >>>>> >>>>> Consider much more easier function: >>>>> >>>>> >>>>> function foo(o) { >>>>> return o.x; >>>>> } >>>>> >>>>> >>>>> print(foo(37)); >>>>> >>>>> >>>>> listing <http://pastebin.com/u0ZM8C3w> >>>>> >>>>> I've got two question: >>>>> 1) 0x36c28f53eecf 47 e8cc92fdff call 0x36c28f5181a0 ;; >>>>> code: contextual, LOAD_IC, GENERIC >>>>> Does that code create new IC stub? Where is the check for IC placed? >>>>> >>>> >>>> That's the call to the IC stub. The stub is created elsewhere >>>> (dynamically, as needed). All the type checks happen inside the stub, not >>>> in the enclosing function. >>>> >>>> >>>>> >>>>> I believe that check should looks like: >>>>> if (actual_type1 == int) -> generate IC stub for int, if it exists >>>>> then we call it >>>>> if (actual_type1 == double) ... >>>>> >>>> >>>> More like: >>>> if (hidden class of o == previously seen hidden class) { call >>>> previously generated handler } >>>> else miss /* call into C++ to create a new handler for the new hidden >>>> class */ >>>> >>>> At least that's the standard "monomorphic" case. The IC system is quite >>>> flexible, each IC can be in one of many different states. >>>> >>>> >>>>> 2) How to remove lines that looks like debug *. For example : debug: >>>>> statement 19 >>>>> >>>> >>>> They're just comments, part of the --code-comments output. Their >>>> purpose is to make it easier for you to trace machine instructions back to >>>> the JavaScript source. >>>> >>>> >>>>> On Tuesday, February 16, 2016 at 2:31:58 PM UTC+6, Jakob Kummerow >>>>> wrote: >>>>>> >>>>>> On Tue, Feb 16, 2016 at 8:10 AM, <[email protected]> wrote: >>>>>> >>>>>>> Thank Ben, but I need to some example: >>>>>>> >>>>>>> function add(a, b) { >>>>>>> return a + b; >>>>>>> } >>>>>>> >>>>>>> >>>>>>> print(add(37, 73)); >>>>>>> I execute this code via d8. >>>>>>> >>>>>>> What is context in that case? >>>>>>> >>>>>> >>>>>> Your function "add" is so simple that it doesn't need a context, and >>>>>> indeed no context is allocated. >>>>>> >>>>>> >>>>>>> I've got the asm listing via --print-code: listing >>>>>>> <http://pastebin.com/NhWyhRDK> >>>>>>> Actually I can't understand why the listing consists so many codes? >>>>>>> The adder function is very simple. >>>>>>> >>>>>>> 0xda955b3eff6 150 49ba0000000025000000 REX.W movq r10, >>>>>>> 0x2500000000 >>>>>>> 0xda955b3f000 160 4152 push r10 >>>>>>> 0xda955b3f002 162 49ba0000000049000000 REX.W movq r10, >>>>>>> 0x4900000000 >>>>>>> 0xda955b3f00c 172 4152 push r10 >>>>>>> 0xda955b3f00e 174 48ba0000000007000000 REX.W movq rdx,0x700000000 >>>>>>> 0xda955b3f018 184 488b7c2418 REX.W movq rdi,[rsp+0x18] >>>>>>> 0xda955b3f01d 189 e85efcffff call 0xda955b3ec80 ;; code >>>>>>> : CALL_IC, GENERIC >>>>>>> 0xda955b3f022 194 488b75f8 REX.W movq rsi,[rbp-0x8] >>>>>>> 0xda955b3f026 198 48890424 REX.W movq [rsp],rax >>>>>>> >>>>>>> >>>>>> ^ That's the compiled top-level code. The compiled code for function >>>>>> "add" is in lines 109 - 170 in your pastebin. You can tell either by >>>>>> looking at the "--- Raw source ---" section, or at the "name = add" line. >>>>>> >>>>>> If you run with --code-comments, you'll get comments embedded into >>>>>> the code that'll explain what each section was generated for. >>>>>> >>>>>> >>>>>>> On Monday, February 15, 2016 at 11:14:58 PM UTC+6, Ben Noordhuis >>>>>>> wrote: >>>>>>> >>>>>>>> On Mon, Feb 15, 2016 at 1:57 PM, <[email protected]> wrote: >>>>>>>> > Hi all! >>>>>>>> > >>>>>>>> > I'm trying to understand the full-codegen compiler in v8. >>>>>>>> > >>>>>>>> > Ok, I've taken the full-codegen code for x64 architecture. >>>>>>>> > >>>>>>>> > As I can see in code, it does following things: >>>>>>>> > Build x64 frame >>>>>>>> > Allocate locals >>>>>>>> > And then allocate context <- this is magic for me >>>>>>>> > >>>>>>>> > The code's: >>>>>>>> > >>>>>>>> > // Possibly allocate a local context. >>>>>>>> > >>>>>>>> > if (info->scope()->num_heap_slots() > 0) { >>>>>>>> > >>>>>>>> > Comment cmnt(masm_, "[ Allocate context"); >>>>>>>> > >>>>>>>> > bool need_write_barrier = true; >>>>>>>> > >>>>>>>> > int slots = info->scope()->num_heap_slots() - >>>>>>>> > Context::MIN_CONTEXT_SLOTS; >>>>>>>> > >>>>>>>> > // Argument to NewContext is the function, which is still in >>>>>>>> rdi. >>>>>>>> > >>>>>>>> > ... >>>>>>>> > >>>>>>>> > >>>>>>>> > What does the full-codegen does here? >>>>>>>> >>>>>>>> The context it allocates is the storage for a function's free >>>>>>>> variables. V8's garbage collector is generational; the write >>>>>>>> barrier >>>>>>>> is for tracking object references from the old space to the new >>>>>>>> space. >>>>>>>> >>>>>>> -- >>>>>>> >>>>>> -- >>> -- >>> v8-dev mailing list >>> [email protected] >>> http://groups.google.com/group/v8-dev >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "v8-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
