This could be useful for developing V8. It's unlikely to be useful for those developing JavaScript using V8 (without huge amounts of work on gdb). For JS developers we have our own debugger that understands a lot of the subtle issues around debugging JS code. For example where and how you can put a breakpoint without messing up garbage collection, the layout of JS objects in memory etc.
A rather more mundane issue is that although we have tried to make a stack frame layout that gdb can walk, it doesn't work for us at the moment. So if we stop in JITed code, gdb can't do a bt that goes all the way back to the C++ frames below. Not knowing our way around gdb we haven't been able to see why that is. 2009/4/1 Robert Henry <[email protected]>: > > A thread has been started on the gdb and llvm mailing lists about > mechanisms for having jitted code and gdb interact in some useful > manner. The originator is Jeffrey Yaskin, of Google, who is working > on the "unladen swallow" project to use llvm to compile python. This > work/outcome might be useful for v8. > > That series of nested postings is included here. > > ---------- Forwarded message ---------- > From: Jeffrey Yasskin <[email protected]> > Date: Tue, Mar 31, 2009 at 12:35 PM > Subject: [unladen-swallow] Fwd: [LLVMdev] Connecting JITted code to gdb > To: Unladen Swallow <[email protected]> > > > > > I just sent this to the LLVM and GDB lists, in the hope that they can > figure out how to debug JITted code for us. If you want to follow that > discussion, you should subscribe to one of those lists, although if > they ask anything Python-specific, I'll cc it back onto here. > > > ---------- Forwarded message ---------- > From: Jeffrey Yasskin <[email protected]> > Date: Tue, Mar 31, 2009 at 12:33 PM > Subject: Re: [LLVMdev] Connecting JITted code to gdb > To: LLVM Developers Mailing List <[email protected]>, [email protected] > > > I'm adding the gdb list because it appears there's currently no way to > tell gdb about newly-JITted code. That is, it's not an LLVM-specific > problem. > > There appear to be two techniques in common use to debug > dynamically-generated code despite this. First, as Evan suggests > below, we can have the JIT print the address range that it's written a > function into, have gdb disassemble that, set breakpoints at > particular addresses, and print variables by knowing what register > they live in. Second, as described at > http://www.mono-project.com/Debugging#Debugging_with_GDB_in_XDEBUG_mode, > we can write out a full object file with dwarf tables, and use > add-symbol-file to get gdb to load that on demand. > > Neither of these is ideal. add-symbol-file is better, but it doesn't > allow us to set breakpoints inside the JITted code until it's > generated, and it doesn't let those breakpoints follow the code as > it's re-optimized and re-translated. It currently also requires user > interaction, but it's possible that we could write a -gdb.py file to > reload the debug information every time the user gets to the gdb > prompt. There may be other problems I haven't though of. > > It would be better to have an interface through which a JITting > library could tell gdb about newly-generated code. This could resemble > the overlay interface > (http://sourceware.org/gdb/current/onlinedocs/gdb_13.html#SEC108) or > the interface through which dynamic loaders tell gdb about > newly-loaded code. There are a couple considerations that are specific > to JITting, of course: > 1. A JIT compiler generates new code frequently, and having to do > lots of extra work, especially while the debugger isn't attached, may > hurt performance. > 2. Translated code gets duplicated, replaced, and freed, and gdb > needs to modify its breakpoints to keep up. > > I don't really know enough about the internals of LLVM or gdb to make > any recommendations, but I think it would be useful to find some way > for them (and other debuggers and JITs) to talk to each other. > > Jeffrey > > On Fri, Mar 27, 2009 at 1:48 PM, Evan Cheng <[email protected]> wrote: >> Run with -debug-only=jit. >> >> Break on line 1148 of JITEmitter.cpp. The debugging message will tell >> you the address and size of the function that was jitted. You can then >> tell gdb to disassemble the code. > > > > -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
