Christian Schafmeister
2013-Apr-23 20:30 UTC
[LLVMdev] Questions about attaching DWARF source code debugging information to generated LLVM-IR.
Hey folks, I'm wrestling with adding DWARF source code file/line information to my generated LLVM-IR from my Common Lisp compiler. I think I'm doing everything properly using the llvm::DIBuilder class - but when I load my Common Lisp application and load a compiled bundle into it I don't seem to be able to access the metadata properly. I can list source lines using "l -f dwarf0.lsp -l 1" but I can't set break-points or do much else. I've prepared a test case and put it in my public folder on dropbox: https://dl.dropboxusercontent.com/u/6229900/dwarf1.txt It's a flat text file containing six sections which you can jump to by searching for "SECTION" (all caps). I've added a few lines at each SECTION entry with thoughts about what might be wrong or what is going on. If one of you debugging gurus could take a few minutes to take a look at it and give me some pointers I'd really, really appreciate it! Best, .Chris.
Christian Schafmeister
2013-Apr-23 20:55 UTC
[LLVMdev] Questions about attaching DWARF source code debugging information to generated LLVM-IR.
I didn't make it clear that I load my Common Lisp application into "lldb" and then load a compiled bundle into my application using dlopen (I'm on OS X and I'm generating a kind of shared library called a "bundle"). Once everything is loaded, the functions from the bundle are accessible to my Common Lisp environment but I don't seem to be able to access the bundle metadata properly from lldb. Best, .Chris. On Apr 23, 2013, at 4:30 PM, Christian Schafmeister <meister at temple.edu> wrote:> > Hey folks, > > I'm wrestling with adding DWARF source code file/line information to my generated LLVM-IR from my Common Lisp compiler. > > I think I'm doing everything properly using the llvm::DIBuilder class - but when I load my Common Lisp application and load a compiled bundle into it I don't seem to be able to access the metadata properly. > > I can list source lines using "l -f dwarf0.lsp -l 1" but I can't set break-points or do much else. > > I've prepared a test case and put it in my public folder on dropbox: https://dl.dropboxusercontent.com/u/6229900/dwarf1.txt > > It's a flat text file containing six sections which you can jump to by searching for "SECTION" (all caps). > I've added a few lines at each SECTION entry with thoughts about what might be wrong or what is going on. > > If one of you debugging gurus could take a few minutes to take a look at it and give me some pointers I'd really, really appreciate it! > > Best, > > .Chris. > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Malea, Daniel
2013-Apr-23 21:18 UTC
[LLVMdev] Questions about attaching DWARF source code debugging information to generated LLVM-IR.
Hmm, are you using a version of LLVM with asserts enabled (I.e. A debug build)? I cut-and-paste your IR into a text file and ran (a debug version of) llc on it, which caused the following assertion failure that seems related to some DWARF mishap: llc: ../lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1400: void llvm::DwarfDebug::beginFunction(const llvm::MachineFunction*): Assertion `TheCU && "Unable to find compile unit!"' failed. 0 llc 0x00000000011d3ad6 1 llc 0x00000000011d3d5d 2 llc 0x00000000011d37ac 3 libpthread.so.0 0x00007fa2aa6a7cb0 4 libc.so.6 0x00007fa2a9afd425 gsignal + 53 5 libc.so.6 0x00007fa2a9b00b8b abort + 379 6 libc.so.6 0x00007fa2a9af60ee 7 libc.so.6 0x00007fa2a9af6192 8 llc 0x00000000009b0799 9 llc 0x000000000099a197 10 llc 0x000000000077b14d 11 llc 0x0000000000cd7b81 12 llc 0x00000000010d2aa0 13 llc 0x00000000010d2c9b 14 llc 0x00000000010d3013 15 llc 0x00000000010d3628 16 llc 0x00000000010d383b 17 llc 0x000000000042781c 18 llc 0x00000000004267cd 19 libc.so.6 0x00007fa2a9ae876d __libc_start_main + 237 20 llc 0x0000000000426129 Stack dump: 0. Program arguments: ./llvm/build-cmake/bin/llc christian.ll -o christian 1. Running pass 'Function Pass Manager' on module 'christian.ll'. 2. Running pass 'X86 Assembly / Object Emitter' on function '@repl' Aborted (core dumped) It looks like something is wrong with one of your function definition. Glancing at the IR though, I can't tell what though.. (PS. I attached a debugger and got a partial dump of the MachineFunction that causes the assertion in beginFunction. See attached. Good luck, Dan On 2013-04-23 4:55 PM, "Christian Schafmeister" <chris.schaf at verizon.net> wrote:> >I didn't make it clear that I load my Common Lisp application into "lldb" >and then load a compiled bundle into my application using dlopen (I'm on >OS X and I'm generating a kind of shared library called a "bundle"). Once >everything is loaded, the functions from the bundle are accessible to my >Common Lisp environment but I don't seem to be able to access the bundle >metadata properly from lldb. > >Best, > >.Chris. > >On Apr 23, 2013, at 4:30 PM, Christian Schafmeister <meister at temple.edu> >wrote: > >> >> Hey folks, >> >> I'm wrestling with adding DWARF source code file/line information to my >>generated LLVM-IR from my Common Lisp compiler. >> >> I think I'm doing everything properly using the llvm::DIBuilder class - >>but when I load my Common Lisp application and load a compiled bundle >>into it I don't seem to be able to access the metadata properly. >> >> I can list source lines using "l -f dwarf0.lsp -l 1" but I can't set >>break-points or do much else. >> >> I've prepared a test case and put it in my public folder on dropbox: >>https://dl.dropboxusercontent.com/u/6229900/dwarf1.txt >> >> It's a flat text file containing six sections which you can jump to by >>searching for "SECTION" (all caps). >> I've added a few lines at each SECTION entry with thoughts about what >>might be wrong or what is going on. >> >> If one of you debugging gurus could take a few minutes to take a look >>at it and give me some pointers I'd really, really appreciate it! >> >> Best, >> >> .Chris. >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: machine_assert.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130423/ada82ffd/attachment.txt>
Possibly Parallel Threads
- [LLVMdev] Questions about attaching DWARF source code debugging information to generated LLVM-IR.
- [LLVMdev] Questions about attaching DWARF source code debugging information to generated LLVM-IR.
- [LLVMdev] Questions about attaching DWARF source code debugging information to generated LLVM-IR.
- [LLVMdev] Questions about attaching DWARF source code debugging information to generated LLVM-IR.
- [LLVMdev] MCJIT and DWARF debugging info and lldb