[LLVMdev] Questions about attaching DWARF source code debugging information to generated LLVM-IR.

Christian Schafmeister chris.schaf at verizon.net
Tue Apr 23 21:37:20 PDT 2013 

One other thing that may or may not illuminate the situation.

When I run under gdb (on OS X 10.8.3 this is an ancient version of gdb 6.3.5 - but it works with clang compiled C++ code) I get the following error when I try to list a line in dwarf1.lsp:

Dwarf Error: Cannot handle DW_FORM_<unknown> in DWARF reader [in module /Users/meister/Development/cando/src/tests/core/dwarf1.bundle]
(gdb)


---------- full gdb transcript follows ----------

(gdb) run
Reading symbols for shared libraries ++++++++++++++++++++++.............................. done
Using lisp-source-directory --> /Users/meister/Development/cando/src/lisp
../../src/core/lisp.cc:206 BRIDGE-COMMON-LISP startup
../../src/core/corePackage.cc:393 - exported symbol[*LOAD-VERBOSE*]
../../src/core/foundation.cc:627 - The symbol[LOGIOR] has already been assigned a function and will not be redefined
../../src/core/foundation.cc:627 - The symbol[NAN] has already been assigned a function and will not be redefined
Loading interpreted file: /Users/meister/Development/cando/src/lisp/brcl/cmp/jit-setup.lsp
Currently the (LOG x) macro is: ( LOG X )
Compiler LOG macro will slow down compilation

Useful commands:
(load-boot stage &key :interp t )   - Load the minimal system
(compile-boot stage &key :reload t) - Compile whatever parts of the system have changed
(clean-boot stage)                  - Remove all boot files after after-file
Available modules: ( LSP/FOUNDATION LSP/EXPORT LSP/DEFMACRO LSP/HELPFILE LSP/EVALMACROS LSP/LOGGING LSP/MAKEARRAY :TINY :PRE-CMP CMP/CMPSETUP CMP/CMPGLOBALS CMP/CMPVAR CMP/COMPILE-MAIN CMP/LLVM-IR CMP/EXCEPTION-HANDLING CMP/DEBUGINFO CMP/LAMBDA-LIST CMP/COMPILE-VAR-LOOKUPS CMP/CMPQUOTE CMP/COMPILER CMP/COMPILE-FILE CMP/COMPILE-BUNDLE CMP/CMPWALK LSP/SETF LSP/SETFREST LSP/LISTLIB :CMP :STAGE1 LSP/PREDLIB LSP/SHARPMACROS LSP/CMUUTIL LSP/SEQMACROS LSP/SEQLIB LSP/SEQ LSP/ASSERT LSP/DEFSTRUCT LSP/IOLIB LSP/MODULE LSP/TRACE LSP/LOOP2 LSP/PACKLIB LSP/DEFPACKAGE LSP/FORMAT :STAGE2 CLOS/PACKAGE CLOS/HIERARCHY CMP/CMPREPL CLOS/CPL CLOS/STD-SLOT-VALUE CLOS/SLOT CLOS/BOOT CLOS/KERNEL CLOS/METHOD CLOS/COMBIN CLOS/STD-ACCESSORS CLOS/DEFCLASS CLOS/SLOTVALUE CLOS/STANDARD CLOS/BUILTIN CLOS/CHANGE CLOS/STDMETHOD CLOS/GENERIC CLOS/FIXUP :FRONT CLOS/CONDITIONS CLOS/PRINT CLOS/STREAMS LSP/PPRINT :CLOS )

BRIDGE-COMMON-LISP (copyright Christian E. Schafmeister 2013) - 1.0

CORE>>> (defun gdb () (break "break"))

; --> #<INTERPRETED :name GDB :llh #<LAMBDA-LIST-HANDLER :ClassifiedSymbols Cons_O::nil  :comment "">  :environment #[VALUE-ENVIRONMENT :id 27874
      ----NO METADATA----
       ]
 :declares Cons_O::nil :docstring """"  :code ((BLOCK GDB ( BREAK "break" )  )  ) >

CORE>>> (load-bundle "dwarf1.bundle")
Reading symbols for shared libraries .... done
Found function ___user_dwarf1 at address 0x1057ab7d0

("First line x -->" 1  ) 
"second line" break
../../src/core/primitives.cc:354 af_debug --> nil
  Frame   9, file "-StringInStream-", line 1, col 16,    iL-Func, in BREAK
       ( BREAK "break" )
The following restarts are available:
ABORT      a    Abort to REPL
Frame-9-Dbg(+ENV)[1]>
Program received signal SIGINT, Interrupt.
0x00007fff95666ffa in read ()
(gdb) l dwarf1.lsp:1
Dwarf Error: Cannot handle DW_FORM_<unknown> in DWARF reader [in module /Users/meister/Development/cando/src/tests/core/dwarf1.bundle]
(gdb)




On Apr 24, 2013, at 12:20 AM, Christian Schafmeister <chris.schaf at verizon.net> wrote:

> 
> 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