> Is there some condition that would lead to the x64 code generator placing > the > function somewhere else?
No. I don't think so. You can take a look at FullCodeGenerator::Generate to see the prologue. My guess would be that context is not yet on the stack when we stop at the beginning of g. The structure of the frame is different depending on the pc position inside the function (we might be in the prologue, in the body or in the epilogue). > Yes, because otherwise gdb will ignore the pretty printer. Yeah. I completely forgot about the pretty printer. Disregard my comments on the matter. It's much better to have pretty printer that would grok types and display things in human readable form. Though current pretty printer is a bit too "strange" for embedders. But we can improve it overtime. I think I am going to land this CL as is. We can investigate problems with x64 separately. Another interesting thing to investigate is that gdb on my linux box started crashing when I enable --gdbjit on simple examples. I sense it might be related to strange duplication we have in abbrev/debug_info section. But I think before we start fixing anything else we need to unify abbrev and debug_info. It should be possible to build both content (debug_info) and description (abbrev) simultaneously. -- Vyacheslav Egorov On Wed, Jun 29, 2011 at 8:25 PM, <[email protected]> wrote: > 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
