On 2011/06/29 12:12:02, Vyacheslav Egorov wrote:
I was doing some prelanding tests and found a couple of problems:
1) __function does not work for x64 at least on my simple test:
function g () { return 1; }
function f () {
var ret = 0;
for (var i = 1; i < 10000000; i++) {
ret += g ();
}
return ret;
}
f()
set breakpoint in g with b g
v8print __function
Printed some SMI for me.
That's pretty interesting; in ia32 this works fine, and if you drop out of
the
function everything's OK too. The context appears to be correct in both
instances. Right now I am calculating the address of the function slot as:
w->Write<uint8_t>(DW_OP_fbreg);
w->WriteSLEB128(JavaScriptFrameConstants::kFunctionOffset);
(which on x64 turns into rbp-0x10)
and the context slot as:
w->Write<uint8_t>(DW_OP_fbreg);
w->WriteSLEB128(StandardFrameConstants::kContextOffset);
(which on x64 turns into rbp-0x8)
Is there some condition that would lead to the x64 code generator placing
the
function somewhere else?
2) It's a bit unhandy that we declare locals to be some pointer sized
structure.
User can't use normal print to print their values. See comment below. Is
it
intentional?
Yes, because otherwise gdb will ignore the pretty printer. I had a version
previously using DW_ATE_address and DW_TAG_base_type, but felt that it was
clearer if the user would see SMIs properly shifted and heap pointers
identified.
3) I am a bit concerned that abbrev generation and DebugInfoSection are
not
glued together. This is completely unrelated to this CL but I think if we
start
putting more and more stuff there we'll suffer huge headache if we don't
hide
them both under the same abstraction that writes both abbrevs and debug
info
sections.
Agreed; I'll look into ways to address this in a future CL.
http://codereview.chromium.org/6995161/diff/6003/src/gdb-jit.cc
File src/gdb-jit.cc (right):
http://codereview.chromium.org/6995161/diff/6003/src/gdb-jit.cc#newcode1337
src/gdb-jit.cc:1337: w->WriteULEB128(DW_TAG_STRUCTURE_TYPE);
What about using DW_TAG_base_type with DW_ATE_address instead of
DW_TAG_STRUCTURE_TYPE?
I think this would allow GDB to produce something meaningfull when you say
"print __function" instead of just ().
It would be even better if we could hook type of locals to be
v8::internal::Object* but I can't grok how to do it just from DWARF2 spec.
I'll
ask Paul whether this is possible.
Is there a way to do this without depending on the way gcc mangles names
(or is
that not an issue here)?
http://codereview.chromium.org/6995161/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
