[llvm-commits] Add option to emit ELF symbol files for debugging the LLVM JIT with GDB

Reid Kleckner rnk at mit.edu
Tue Sep 1 13:32:57 PDT 2009


2009/9/1 Török Edwin <edwintorok at gmail.com>:
> On 2009-09-01 21:38, Reid Kleckner wrote:
>> Ping?  Please review.  My internship is over and I'd like to finish
>> this up before I start classes.
>>
>> Reid
>>
>> On Fri, Aug 21, 2009 at 7:53 PM, <reid.kleckner at gmail.com> wrote:
>>
>>> Hello LLVM devs,
>>>
>>> I've been working on a debugging interface between GDB and LLVM, and I'd
>>> like to get comments on the LLVM side of the interface now that the GDB
>>> side has been committed.  I don't plan to check this in until after the
>>> code freeze.  Please take a look on Rietveld.  I expect to iterate on
>>> this a couple more times.
>>>
>>> Here's the description of the change from Rietveld:
>>> ---------------------
>>>
>>> This patch implements the JIT side of the GDB JIT debugging interface
>>> that I added to GDB.  To enable this feature, either build the JIT in
>>> debug mode to enable it by default or pass -jit-emit-debug to lli.
>>>
>>> Right now, the only debug information that this communicates to GDB is
>>> call frame information, since it's already being generated to support
>>> exceptions in the JIT.  Eventually, when DWARF generation isn't tied so
>>> tightly to AsmPrinter, it will be easy to push that information to GDB
>>> through this interface.
>>>
>
> OProfileJITEventListener is already able to send file:line number
> information
> to oprofile. Although it does this via the opagent library, and doesn't
> have to emit an ELF itself,
> the debug info you need for line numbers is there.
> I think there could be a global function in LLVM, that given an address
> will print filename:sourceline info.
> One could manually call that from gdb, just as you would call
> Module->dump(), and could be an aid in debugging,
> until full DWARF debug info can be emitted for JITed code.
> This could be independent from your GDB <-> JIT interface, for example
> as another JITEventListener.

Speaking of which, the JITDebugRegisterer should be a JITEventListener.

I think that would be useful for debugging, but for this change I'm
mostly concerned with getting proper backtraces, since that is what
you need to debug 95% of the time.

>>> Here's a step-by-step breakdown of how the feature works:
>>> - 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 an in-memory ELF file with a symbol for
>>> the function.
>>>
>
> It seems you create a new ELF for each function being JITed, could this
> be a single ELF for the entire program?

The interface supports multiple functions in the ELF, but since GDB
can stop the program at any time, we figured it was best to tell GDB
about each function as soon as it is created.  GDB only needs the
debug info when it tries to produce a trace or set a breakpoint, so it
could be generated lazily, but we decided that this was more trouble
than it was worth.

Reid




More information about the llvm-commits mailing list