[LLVMdev] Preliminary patch for GDB support for JIT

[Eric Christopher]

On Jul 8, 2009, at 11:41 AM, Reid Kleckner wrote:

> Right now, GDB has no way to be told about JITed code.  I'm working on
> adding such an interface, and the LLVM JIT would be the first client.
> The interface is evolving, and I'll admit that right now it's
> downright terrible.  Here's how it works right now:
>
> - The JIT generates the machine code and DWARF call frame info
> (.eh_frame/.debug_frame) for a function into memory.
> - The JIT copies that info into a temporary ELF file with a symbol for
> the function.
> - The JIT stuffs the filename and text address (function start) into a
> global struct at a special symbol that GDB knows about.
> - The JIT calls a function marked noinline that GDB knows about and
> has put an internal breakpoint in.
> - GDB takes control when the breakpoint fires, reads the filename and
> addr from the struct, and does the equivalent of an 'add-symbol-file'
> command from the prompt with those two arguments.
> - The JIT continues, and the next time we stop the program, we are
> able to produce a proper backtrace.
>

I've been thinking about this lately myself and this is along the  
lines I
was going as well.

> For reference, here is the corresponding patch against GDB:
> http://web.mit.edu/rnk/www/jit-patch.diff
>

This appears to be missing some hunks...

> And finally, the patch to LLVM is attached and uploaded to Rietveld:
> http://codereview.appspot.com/91042/show
>

In general I'd like to see the ELF support separated from the main
interface. It makes any other platform support require a complete
refactor :)

> I know this code is sketchy and preliminary, but it's useful for us,
> and I have plans to improve it:
> http://wiki.llvm.org/HowTo:_Tell_GDB_about_JITted_code

I'm not entirely sure about the lazy debug symbols part, but
as far as I can tell neither are you :)

The rest of it seems reasonable to me.

Note that I can't approve the patch anyhow :)

-eric