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. --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
