Landed http://code.google.com/p/v8/source/detail?r=8483
-- Vyacheslav Egorov On Thu, Jun 30, 2011 at 1:36 PM, Vyacheslav Egorov <[email protected]> wrote: >> 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
