[LLVMdev] Questions about attaching DWARF source code debugging information to generated LLVM-IR.
Christian Schafmeister
chris.schaf at verizon.net
Tue Apr 23 21:20:43 PDT 2013
I upgraded my versions of llvm, clang and compiler-rt to the top-of-tree versions from last night (r180162, April 24).
I recompiled debug versions of llvm, clang and my code.
I then regenerated my test case and the results were the same - I can list lines of dwarf1.lsp in lldb but I can't set break-points or do anything else (what else should I be able to do?).
The updated file that describes the test case is at: https://dl.dropboxusercontent.com/u/6229900/dwarf1_new.txt
I did have to make a few changes to my code to make it work with the latest llvm.
In particular DIBuilder::createCompileUnit required an additional parameter "SplitName".
But when I added that parameter and fixed a few other things the results were the same.
I think I'm generating the DWARF compile_unit, subprogram, lexical-block, and line-number information correctly but I can't seem to get it to work with lldb.
If anyone can take a look at it and suggest what I'm doing wrong or suggest tools that I can use to debug this problem - I'd greatly appreciate it.
Best,
.Chris.
On Apr 23, 2013, at 6:32 PM, "Malea, Daniel" <daniel.malea at intel.com> wrote:
> I built SVN revision 180023, looks like it's slightly newer than yours:
>
> LLVM (http://llvm.org/):
> LLVM version 3.3svn
> DEBUG build with assertions.
> Built Apr 22 2013 (14:26:17).
> Default target: x86_64-unknown-linux-gnu
> Host CPU: corei7-avx
>
> Registered Targets:
> aarch64 - AArch64
> arm - ARM
> cpp - C++ backend
> hexagon - Hexagon
> mblaze - MBlaze
> mips - Mips
> mips64 - Mips64 [experimental]
> mips64el - Mips64el [experimental]
> mipsel - Mipsel
> msp430 - MSP430 [experimental]
> nvptx - NVIDIA PTX 32-bit
> nvptx64 - NVIDIA PTX 64-bit
> ppc32 - PowerPC 32
> ppc64 - PowerPC 64
> sparc - Sparc
> sparcv9 - Sparc V9
> thumb - Thumb
> x86 - 32-bit X86: Pentium-Pro and above
> x86-64 - 64-bit X86: EM64T and AMD64
> xcore - XCore
>
>
>
>
> On 2013-04-23 6:26 PM, "Christian Schafmeister" <chris.schaf at verizon.net>
> wrote:
>
>> Dan,
>>
>> Thanks for taking time out to look at this.
>>
>> I cut-and-pasted the IR into a text file and ran the following version of
>> llc on it using "llc -filetype=obj dwarf1_paste.ll" and it didn't report
>> any errors.
>> I'll take a closer look at the CompileUnit DWARF entry in the IR.
>>
>> But in the mean-time, which version of llc are you using?
>>
>> I'm using:
>>
>> LLVM (http://llvm.org/):
>> LLVM version 3.3svn
>> Optimized build with assertions.
>> Built Apr 21 2013 (20:22:16).
>> Default target: x86_64-apple-darwin12.3.0
>> Host CPU: corei7-avx
>>
>> Registered Targets:
>> arm - ARM
>> cpp - C++ backend
>> hexagon - Hexagon
>> mblaze - MBlaze
>> mips - Mips
>> mips64 - Mips64 [experimental]
>> mips64el - Mips64el [experimental]
>> mipsel - Mipsel
>> msp430 - MSP430 [experimental]
>> nvptx - NVIDIA PTX 32-bit
>> nvptx64 - NVIDIA PTX 64-bit
>> ppc32 - PowerPC 32
>> ppc64 - PowerPC 64
>> sparc - Sparc
>> sparcv9 - Sparc V9
>> thumb - Thumb
>> x86 - 32-bit X86: Pentium-Pro and above
>> x86-64 - 64-bit X86: EM64T and AMD64
>> xcore - XCore
>>
>>
>> Best,
>>
>> .Chris.
>>
>>
>>
>> On Apr 23, 2013, at 5:18 PM, "Malea, Daniel" <daniel.malea at intel.com>
>> wrote:
>>
>>> 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
>>>
>>> <machine_assert.txt>
>>
>
More information about the llvm-dev
mailing list