> In this line, the object at 0x7fe8125aa911 is not shown. I assume it is
> placed in "data section".
Well. There is not data section. The object itself lives in the heap.
If you look at relocation information you can see that object
0x7fe8125aa911 is a two element FixedArray.
You can extend Code::Disassemble to print all referenced objects
recursively but that would produce quite a large output with cycles.
Alternatively you can just put a breakpoint into
CodeGenerator::PrintCode, wait until V8 compiles and prints
interesting function and then expect heap state, print objects that
are interesting to you etc.
> In these two lines, the callees are not shown, I suppose CEntry and
> StackCheck are both built-in functions of v8.
They will be printed if you pass --print-code-stubs to V8 (your shell
should be compiled with snapshot=off).
> Basically, my goal is to catch runtime instructions trace (this is the easy
> part) and relate it back to javascript
> source code.
--code-comment will help you to do that.
> Will --gdbjit-dump help? Is this option only available in debug build?
GDBJIT interface produces object that contain debugging information
(like pc to line mapping) but no code. So I don't think --gdbjit-dump
will help you.
--
Vyacheslav Egorov
On Wed, Jul 6, 2011 at 8:03 PM, Zhaoshi Zheng <wingle...@gmail.com> wrote:
> Vyacheslav,
>
> Thanks for your reply. Take this function for example, Benchmark in base.js
> of V8 benchmark suite:
>
> 0x7fe7ed6c2a07 7 49ba11a95a12e87f0000 REX.W movq r10,0x7fe8125aa911
> ;; object: 0x7fe8125aa911 <FixedArray[2]>
>
> In this line, the object at 0x7fe8125aa911 is not shown. I assume it is
> placed in "data section".
>
> 0x7fe7ed6c2a23 35 e8d8d8fdff call 0x7fe7ed6a0300 ;; debug:
> statement 0
> ;; code: STUB,
> CEntry, minor: 0
>
> 0x7fe7ed6c2a2e 46 e80d23feff call 0x7fe7ed6a4d40 ;; code: STUB,
> StackCheck, minor: 0
>
> In these two lines, the callees are not shown, I suppose CEntry and
> StackCheck are both built-in functions of v8.
>
> Basically, my goal is to catch runtime instructions trace (this is the easy
> part) and relate it back to javascript source code. Will --gdbjit-dump help?
> Is this option only available in debug build?
>
> --- Raw source ---
> // A benchmark has a name (string) and a function that will be run to
> // do the performance measurement. The optional setup and tearDown
> // arguments are functions that will be invoked before and after
> // running the benchmark, but the running time of these functions will
> // not be accounted for in the benchmark score.
> function Benchmark(name, run, setup, tearDown) {
> this.name = name;
> this.run = run;
> this.Setup = setup ? setup : function() { };
> this.TearDown = tearDown ? tearDown : function() { };
> }
>
>
>
> --- Code ---
> kind = FUNCTION
> Instructions (size = 72)
> 0x7fe7ed6c2a00 0 55 push rbp
> 0x7fe7ed6c2a01 1 4889e5 REX.W movq rbp,rsp
> 0x7fe7ed6c2a04 4 56 push rsi
> 0x7fe7ed6c2a05 5 57 push rdi
> 0x7fe7ed6c2a06 6 56 push rsi
> 0x7fe7ed6c2a07 7 49ba11a95a12e87f0000 REX.W movq r10,0x7fe8125aa911
> ;; object: 0x7fe8125aa911 <FixedArray[2]>
> 0x7fe7ed6c2a11 17 4152 push r10
> 0x7fe7ed6c2a13 19 6a00 push 0x0
> 0x7fe7ed6c2a15 21 6a00 push 0x0
> 0x7fe7ed6c2a17 23 b804000000 movl rax,0x4
> 0x7fe7ed6c2a1c 28 498d9da0d792fe REX.W leaq rbx,[r13-0x16d2860]
> 0x7fe7ed6c2a23 35 e8d8d8fdff call 0x7fe7ed6a0300 ;; debug:
> statement 0
> ;; code: STUB,
> CEntry, minor: 0
> 0x7fe7ed6c2a28 40 493b6508 REX.W cmpq rsp,[r13+0x8]
> 0x7fe7ed6c2a2c 44 7305 jnc 51 (0x7fe7ed6c2a33)
> 0x7fe7ed6c2a2e 46 e80d23feff call 0x7fe7ed6a4d40 ;; code: STUB,
> StackCheck, minor: 0
> 0x7fe7ed6c2a33 51 498b4598 REX.W movq rax,[r13-0x68]
> 0x7fe7ed6c2a37 55 488be5 REX.W movq rsp,rbp ;; debug:
> statement 513
> ;; js return
> 0x7fe7ed6c2a3a 58 5d pop rbp
> 0x7fe7ed6c2a3b 59 c20800 ret 0x8
> 0x7fe7ed6c2a3e 62 cc int3
> 0x7fe7ed6c2a3f 63 cc int3
> 0x7fe7ed6c2a40 64 cc int3
> 0x7fe7ed6c2a41 65 cc int3
> 0x7fe7ed6c2a42 66 cc int3
> 0x7fe7ed6c2a43 67 cc int3
>
> Deoptimization Output Data (deopt points = 0)
>
> Stack checks (size = 0)
> ast_id pc_offset
>
> RelocInfo (size = 14)
> 0x7fe7ed6c2a09 embedded object (0x7fe8125aa911 <FixedArray[2]>)
> 0x7fe7ed6c2a23 statement position (0)
> 0x7fe7ed6c2a24 code target (STUB) (0x7fe7ed6a0300)
> 0x7fe7ed6c2a2f code target (STUB) (0x7fe7ed6a4d40)
> 0x7fe7ed6c2a37 statement position (513)
> 0x7fe7ed6c2a37 js return
>
>
> On Wed, Jul 6, 2011 at 1:15 PM, Vyacheslav Egorov <vego...@chromium.org>
> wrote:
>>
>> Hi Albert,
>>
>> Can you clarify?
>>
>> What kind of information in your opinion is missing from the
>> --print-code output?
>>
>> You can use --code-comments to make assembly more human readable.
>>
>> Strictly speaking there is not such thing as a translated JS program as
>> whole.
>>
>> V8 compiles different functions separately as application runs. It
>> might compile the same function several times with different
>> compilers.
>>
>> --
>> Vyacheslav Egorov
>>
>>
>> On Wed, Jul 6, 2011 at 7:09 PM, Albert <wingle...@gmail.com> wrote:
>> > Hi,
>> >
>> > I'm studying hardware performance of JS programs. I tried with --print-
>> > code switch with shell sample but the problem is I only got assembly
>> > code. What I would like to have is something like objdump result of C/C
>> > ++ program. Is there a way of doing this?
>> >
>> > Thanks,
>> >
>> > --
>> > v8-users mailing list
>> > v8-users@googlegroups.com
>> > http://groups.google.com/group/v8-users
>> >
>>
>> --
>> v8-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
