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

Bruno Cardoso Lopes bruno.cardoso at gmail.com
Tue Sep 1 12:29:32 PDT 2009


On Tue, Sep 1, 2009 at 3:38 PM, Reid Kleckner<rnk at mit.edu> wrote:
> Ping?  Please review.  My internship is over and I'd like to finish
> this up before I start classes.

You can remove the "leak comment" now

> 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.
>>
>> 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.
>> - The JIT creates a code entry pointing to the ELF buffer and adds it to
>> a linked list hanging off of a global descriptor 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 catches the breakpoint and reads the global descriptor to look for
>> new code.
>> - When sees there is new code, it reads the ELF from the inferior's
>> memory and adds it to itself as an object file.
>> - The JIT continues, and the next time we stop the program, we are able
>> to produce a proper backtrace.
>>
>> Consider running the following program through the JIT:
>>
>> #include <stdio.h>
>> void baz(short z) {
>>  long w = z + 1;
>>  printf("%d, %x\n", w, *((int*)NULL));  // SEGFAULT here
>> }
>> void bar(short y) {
>>  int z = y + 1;
>>  baz(z);
>> }
>> void foo(char x) {
>>  short y = x + 1;
>>  bar(y);
>> }
>> int main(int argc, char** argv) {
>>  char x = 1;
>>  foo(x);
>> }
>>
>> Here is a backtrace before this patch:
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0x2aaaabdfbd10 (LWP 25476)]
>> 0x00002aaaabe7d1a8 in ?? ()
>> (gdb) bt
>> #0  0x00002aaaabe7d1a8 in ?? ()
>> #1  0x0000000000000003 in ?? ()
>> #2  0x0000000000000004 in ?? ()
>> #3  0x00032aaaabe7cfd0 in ?? ()
>> #4  0x00002aaaabe7d12c in ?? ()
>> #5  0x00022aaa00000003 in ?? ()
>> #6  0x00002aaaabe7d0aa in ?? ()
>> #7  0x01000002abe7cff0 in ?? ()
>> #8  0x00002aaaabe7d02c in ?? ()
>> #9  0x0100000000000001 in ?? ()
>> #10 0x00000000014388e0 in ?? ()
>> #11 0x00007fff00000001 in ?? ()
>> #12 0x0000000000b870a2 in llvm::JIT::runFunction (this=0x1405b70,
>> F=0x14024e0, ArgValues=@0x7fffffffe050)
>>   at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT.cpp:395
>> #13 0x0000000000baa4c5 in llvm::ExecutionEngine::runFunctionAsMain
>> (this=0x1405b70, Fn=0x14024e0, argv=@0x13f06f8, envp=0x7fffffffe3b0)
>>   at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:377
>> #14 0x00000000007ebd52 in main (argc=2, argv=0x7fffffffe398,
>> envp=0x7fffffffe3b0) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:208
>>
>> And a backtrace after this patch:
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00002aaaabe7d1a8 in baz ()
>> (gdb) bt
>> #0  0x00002aaaabe7d1a8 in baz ()
>> #1  0x00002aaaabe7d12c in bar ()
>> #2  0x00002aaaabe7d0aa in foo ()
>> #3  0x00002aaaabe7d02c in main ()
>> #4  0x0000000000b870a2 in llvm::JIT::runFunction (this=0x1405b70,
>> F=0x14024e0, ArgValues=...)
>>   at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT.cpp:395
>> #5  0x0000000000baa4c5 in llvm::ExecutionEngine::runFunctionAsMain
>> (this=0x1405b70, Fn=0x14024e0, argv=..., envp=0x7fffffffe3c0)
>>   at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:377
>> #6  0x00000000007ebd52 in main (argc=2, argv=0x7fffffffe3a8,
>> envp=0x7fffffffe3c0) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:208
>>
>> ----------------
>>
>> Thanks!
>> Reid
>>
>> http://codereview.appspot.com/91042
>>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>



-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc




More information about the llvm-commits mailing list