[lldb-dev] I'm having trouble getting lldb to read generated DWARF source line metadata

[Greg Clayton]

On Apr 24, 2013, at 9:49 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote:

> 
> Hey folks,
> 
> I'm writing a Common Lisp compiler that uses LLVM as the back-end.
> 
> I'm generating DWARF source line metadata and I think I'm doing everything correctly but when I load it into the latest version of lldb the line number table is messed up and I can't set breakpoints.
> 
> I've prepared a test case and put it here: https://dl.dropboxusercontent.com/u/6229900/dwarf1_new.txt
> 
> The test case above is a flat text file with six sections separated by they "SECTION" keyword (all-caps).
> 
> I'm using llvm/clang and lldb builds that are Top-of-Tree and less than 48 hours old.
> 
> I know it looks like there is a lot of llvm-IR being generated and its partly because I have a lot of my own debugging code in there and partly because Common Lisp has closures and I'm not yet using escape analysis to optimize away environment passing.
> 
> I'm compiling the Common Lisp code to IR and then compiling that to an object file and linking it into an OS X bundle (like a shared library).
> 
> I'm loading that bundle into my executable using "dlopen" and I'm hoping that the DWARF debugging information makes it into lldb.
> 
> However once I do all that and type:   image dump line-table dwarf1.lsp     All I get is:

In order for DWARF to be linked into the final output, your executable must contain a debug map. The debug map consists of STAB entries in the mach-o symbol table of the main executable. A quick example:

% cat main.c
int 
a_function_to_call()
{ 
    return 0;
}

int main (int argc, char const *argv[], char const *envp[])
{
    return a_function_to_call();
}
% clang -g -O0 -c main.c
% clang -g -O0 main.o

Now we can use dsymutil to dump the raw mach-o symbol table by using the "-s" option:

% dsymutil -s a.out
----------------------------------------------------------------------
Symbol table for: 'a.out' (x86_64)
----------------------------------------------------------------------
Index    n_strx   n_type             n_sect n_desc n_value
======== -------- ------------------ ------ ------ ----------------
[     0] 00000002 64 (N_SO         ) 00     0000   0000000000000000 '/tmp/'
[     1] 00000008 64 (N_SO         ) 00     0000   0000000000000000 'main.c'
[     2] 0000000f 66 (N_OSO        ) 03     0001   0000000051795dc5 '/private/tmp/main.o'
[     3] 00000001 2e (N_BNSYM      ) 01     0000   0000000100000f10
[     4] 00000023 24 (N_FUN        ) 01     0000   0000000100000f10 '_a_function_to_call'
[     5] 00000001 24 (N_FUN        ) 00     0000   0000000000000010
[     6] 00000001 4e (N_ENSYM      ) 01     0000   0000000000000010
[     7] 00000001 2e (N_BNSYM      ) 01     0000   0000000100000f20
[     8] 00000037 24 (N_FUN        ) 01     0000   0000000100000f20 '_main'
[     9] 00000001 24 (N_FUN        ) 00     0000   0000000000000025
[    10] 00000001 4e (N_ENSYM      ) 01     0000   0000000000000025
[    11] 00000001 64 (N_SO         ) 01     0000   0000000000000000
[    12] 0000003d 0f (     SECT EXT) 01     0010   0000000100000000 '__mh_execute_header'
[    13] 00000051 0f (     SECT EXT) 01     0000   0000000100000f10 '_a_function_to_call'
[    14] 00000065 0f (     SECT EXT) 01     0000   0000000100000f20 '_main'
[    15] 0000006b 01 (     UNDF EXT) 00     0100   0000000000000000 'dyld_stub_binder'

Note that there are STAB entries like N_SO (symbols 0, 1 and 11) which contain the link information for a source file. The N_OSO (symbol 2)has a "n_desc" set to 0x0001 and the name points to the .o file. The N_FUN entry 4 defines where the function _a_function_to_call was linked, and the following N_FUN with no name contains the size of the _a_function_to_call function.

Does you main executable have this debug map? If so, then dsymutil will be able to link your debug info. If not, then you will need to make one. Typically the linker does this all for you so I am guessing there is something wrong with the DWARF in the .o file.

Feel free to send me the .o file (off the mailing list) and the executable and I can take a look.

Greg Clayton