MCJIT and DWARF debugging info and lldb

Project Infrastructure LLVM Dev List Archives
1

Hey folks, I've written a Common Lisp compiler using LLVM as the
back end. I switched to MCJIT a couple of days ago. I generate DWARF
debugging information for each Compile Unit, Function, LexicalBlock and
line numbers (using DIBuilder). (I'm on OS X 10.8.5;
XCode 5.0; ToT LLVM/Clang build rev 192521)

When I check my backtraces in lldb (stock lldb from Xcode 5.0) I don't see my DWARF debugging info
as I expected - should I be? What is the status of DWARF debugging with
MCJIT?

Here's an example where I define three functions A, B, and C where A
generates a backtrace (using backtrace(3) and backtrace_symbols(3))
and B calls A and C calls B.

The backtrace entries at 6, 10, 14 are my functions a, b, and c.
All there is is entries like: "??? <white-space> 0x00000001097ee44b 0x0 + 4454278219"

(defun a () (core::backtrace))

A

(defun b () (a))

B

(defun c () (b))

C

(c)

(c)

Backtrace: 0 libcore_opt.dylib 0x0000000103a61687 _ZN4core12af_backtraceEv + 55
Backtrace: 1 libcore_opt.dylib 0x0000000103a62c50 _ZN4core27ActivationFrameFunctionPtrTIvvvvvvvvvvvvvvvvvE8activateEPFvvERKN3mem9smart_ptrINS_17ActivationFrame_OEEE + 64
Backtrace: 2 libcore_opt.dylib 0x0000000103a62b12 _ZN4core30ActivationFrameFunctionWrapPtrIvvvvvvvvvvvvvvvvvE8activateERKN3mem9smart_ptrINS_17ActivationFrame_OEEE + 18
Backtrace: 3 libcore_opt.dylib 0x0000000103c8c3c1 _ZN4core9BuiltIn_O6INVOKEERKN3mem9smart_ptrINS_17ActivationFrame_OEEE + 1137
Backtrace: 4 libllvmo_opt.dylib 0x000000010364758c _Z47proto_invokePossibleMultipleValueSymbolFunctionPN3mem9smart_ptrIN4core8Symbol_OEEEPNS0_INS1_17ActivationFrame_OEEE + 1196
Backtrace: 5 libllvmo_opt.dylib 0x000000010363ffa7 mv_invokePossibleMultipleValueSymbolFunction + 23
Backtrace: 6 ??? 0x00000001097ee44b 0x0 + 4454278219
Backtrace: 7 libcore_opt.dylib 0x0000000103c8d50f _ZN4core18CompiledFunction_O6INVOKEERKN3mem9smart_ptrINS_17ActivationFrame_OEEE + 463
Backtrace: 8 libllvmo_opt.dylib 0x000000010364758c _Z47proto_invokePossibleMultipleValueSymbolFunctionPN3mem9smart_ptrIN4core8Symbol_OEEEPNS0_INS1_17ActivationFrame_OEEE + 1196
Backtrace: 9 libllvmo_opt.dylib 0x000000010363ffa7 mv_invokePossibleMultipleValueSymbolFunction + 23
Backtrace: 10 ??? 0x00000001097f244b 0x0 + 4454294603
Backtrace: 11 libcore_opt.dylib 0x0000000103c8d50f _ZN4core18CompiledFunction_O6INVOKEERKN3mem9smart_ptrINS_17ActivationFrame_OEEE + 463
Backtrace: 12 libllvmo_opt.dylib 0x000000010364758c _Z47proto_invokePossibleMultipleValueSymbolFunctionPN3mem9smart_ptrIN4core8Symbol_OEEEPNS0_INS1_17ActivationFrame_OEEE + 1196
Backtrace: 13 libllvmo_opt.dylib 0x000000010363ffa7 mv_invokePossibleMultipleValueSymbolFunction + 23
Backtrace: 14 ??? 0x00000001097f444b 0x0 + 4454302795
Backtrace: 15 libcore_opt.dylib 0x0000000103c8d50f _ZN4core18CompiledFunction_O6INVOKEERKN3mem9smart_ptrINS_17ActivationFrame_OEEE + 463
Backtrace: 16 libllvmo_opt.dylib 0x000000010364758c _Z47proto_invokePossibleMultipleValueSymbolFunctionPN3mem9smart_ptrIN4core8Symbol_OEEEPNS0_INS1_17ActivationFrame_OEEE + 1196
Backtrace: 17 libllvmo_opt.dylib 0x000000010363ffa7 mv_invokePossibleMultipleValueSymbolFunction + 23
Backtrace: 18 ??? 0x00000001097f611c 0x0 + 4454310172
Backtrace: 19 libcore_opt.dylib 0x0000000103c8d50f _ZN4core18CompiledFunction_O6INVOKEERKN3mem9smart_ptrINS_17ActivationFrame_OEEE + 463
Backtrace: 20 libcore_opt.dylib 0x0000000103df6397 _ZN4core4eval30applyFunctionToActivationFrameEN3mem9smart_ptrINS_10Function_OEEERKNS2_INS_17ActivationFrame_OEEE + 103
Backtrace: 21 libcore_opt.dylib 0x0000000103dd06c3 _ZN4core4eval5applyEN3mem9smart_ptrINS_3T_OEEERKNS2_INS_17ActivationFrame_OEEE + 483
Backtrace: 22 libcore_opt.dylib 0x0000000103dcf33f _ZN4core14af_evalWithEnvEN3mem9smart_ptrINS_3T_OEEENS1_INS_13Environment_OEEEbbb + 1055
Backtrace: 23 libcore_opt.dylib 0x0000000103e0512f _ZN4core27ActivationFrameFunctionPtrTIN3mem15multiple_valuesINS_3T_OEEENS1_9smart_ptrIS3_EENS5_INS_13Environment_OEEEbbbvvvvvvvvvvvE8activateEPFS4_S6_S8_bbbERKNS5_INS_17ActivationFrame_OEEE + 655
Backtrace: 24 libcore_opt.dylib 0x0000000103e04e42 _ZN4core30ActivationFrameFunctionWrapPtrIN3mem15multiple_valuesINS_3T_OEEENS1_9smart_ptrIS3_EENS5_INS_13Environment_OEEEbbbvvvvvvvvvvvE8activateERKNS5_INS_17ActivationFrame_OEEE + 18
Backtrace: 25 libcore_opt.dylib 0x0000000103c8c3c1 _ZN4core9BuiltIn_O6INVOKEERKN3mem9smart_ptrINS_17ActivationFrame_OEEE + 1137
Backtrace: 26 libllvmo_opt.dylib 0x000000010364758c _Z47proto_invokePossibleMultipleValueSymbolFunctionPN3mem9smart_ptrIN4core8Symbol_OEEEPNS0_INS1_17ActivationFrame_OEEE + 1196
Backtrace: 27 libllvmo_opt.dylib 0x000000010363ffa7 mv_invokePossibleMultipleValueSymbolFunction + 23
Backtrace: 28 _image.bundle 0x000000010b5771c8 REP + 1816
Backtrace: 29 ??? 0x000000010d71dd50 0x0 + 4520533328

2

MCJIT attempts to register DWARF debugging information with ELF objects, but I don't believe it does so with MachO. This is a historical artifact due to the fact that those of us who worked on the ELF part of this didn't know how to do the same thing with MachO. Notably, to get it to work correctly RuntimeDyldELF updates some headers to point to the live code before it is registered.

We have a working implementation of the Linux version of LLDB supporting MCJIT debugging, but I'm not sure it has been committed to trunk.

It would require some effort to get this working with MachO objects, but I don't think it would be a huge effort for someone who knows the MachO format well.

-Andy

3

Andy,

Thank you for following up. I'm developing this to run on Linux in
parallel so at least I could debug there. I'm also glad that I left my
home-brew debugging callbacks in my generated code - that will always
work although it's much heavier-weight than DWARF.

I would love to test any code that you have that supports LLDB debugging
of MCJIT DWARF debug info.

Perhaps I could help get MCJIT debugging working on MachO - although I
don't have a clue how to go about it. Maybe we could chat on #llvm and
we could evaluate if there is any chance I could help with this or if we
should wait until someone more versed in MachO steps up.

"Kaylor, Andrew" <andrew.kaylor@intel.com> writes: