How does LLDB locate the DWARF information stored inside MACH-O .o files produced by LLVM and LLD?

When I make a simple test program and call abort() and use LLDB to debug it, it has address-to-line mapping. If I then delete the .o file and run LLDB again, it loses the address-to-line mapping. So there must be DWARF info, or otherwise address-to-line info in the .o file.

I’m parsing the MACH-O executable, which has a LC_SYMTAB entry, and one of the entries is the file path of the .o file. So I can find the file that way. Then I parse the MACH-O .o file, which also has the LC_SYMTAB, as well as an LC_SEGMENT_64 and LC_DATA_IN_CODE, and then finally a LC_DYSYMTAB. But I don’t see where the address-to-line information is, or any DWARF information.

Where is LLDB getting this address-to-line info?

You’ll need to go a bit further than the load commands - I don’t know much about MachO files, so I’m just reading: https://lowlevelbits.org/parsing-mach-o-files/ and https://samhuri.net/posts/2010/01/basics-of-the-mach-o-file-format - so inside the section (described by the LC_SEGMENT_64) are probably a bunch of sections, including debug info sections. Tools like llvm-objdump will show you those (llvm-objdump -h), and also tools like llvm-dwarfdump can print the contents of the debug info sections (those with names starting with “__debug”) in human-readable form.

Thanks David.

I figured it out. Here’s the scoop:

The executable has a LC_SYMTAB. One of those nlist_64 entries has the string set to the .o file path, and the n_type set to N_OSO.
So you can go from symbol to .o file.
Then you go read the .o file, and the first load command is LC_SEGMENT_64. That has some number of sections following it, among which are the DWARF sections.

I had tried this, but I forgot to increment a pointer in a loop, so I thought all the sections were the same as the first one. D’oh!

Regards,

-Andrew

Thanks David.

I figured it out. Here’s the scoop:

The executable has a LC_SYMTAB. One of those nlist_64 entries has the string set to the .o file path, and the n_type set to N_OSO.
So you can go from symbol to .o file.

Correct. You can use dsymutil -s to dump the symbol table. If you run dsymutil on the binary it will archive the debug info in a .dSYM bundle and then it’s safe to remove the .o files.

http://wiki.dwarfstd.org/index.php?title=Apple%27s_%22Lazy%22_DWARF_Scheme

– adrian