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

Christian Schafmeister chris.schaf at verizon.net
Tue Apr 23 21:39:55 PDT 2013 

Oh, and I cooked up a bogus function type for all of the functions - it returns an i32 and takes no arguments.  
I was hoping that I could defer dealing with types until later down the road.

Could that be my problem here?


Best,

.Chris.



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

> 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