Fantastic - this will be super useful. On Thu, Jun 30, 2011 at 9:27 AM, Luke Zarko <[email protected]> wrote:
> 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
