Excellent! I will look at unifying abbreviations and content next. With any luck, this will make gdb happier.
On Thu, Jun 30, 2011 at 4:54 AM, Vyacheslav Egorov <[email protected]>wrote: > 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
