Christian Schafmeister
2013-Apr-24 04:20 UTC
[LLVMdev] Questions about attaching DWARF source code debugging information to generated LLVM-IR.
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> >> >
Christian Schafmeister
2013-Apr-24 04:37 UTC
[LLVMdev] Questions about attaching DWARF source code debugging information to generated LLVM-IR.
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>
>>>
>>
>
Christian Schafmeister
2013-Apr-24 04:39 UTC
[LLVMdev] Questions about attaching DWARF source code debugging information to generated LLVM-IR.
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> >>>> >>> >> >
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] A weird, reproducable problem with MCJIT