I’m sharing some notes on a strange LLDB issue I hit locally, in case anyone else hits the same problem. The symptoms are symbols unexpectedly not working for some modules and/or warning messages complaining about “unsupported DW_FORMs”, ex:
warning: (x86_64) /lib/x86_64-linux-gnu/libz.so.1.2.8 unsupported DW_FORM values: 0x2 0x1b 0x1c 0x1d 0x1e 0x1f 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 … lots more values …
Tools like dwarfdump, objdump and realelf didn’t raise any complains about the affected symbols so the symbols themselves seemed fine. The LLDB warning was fired during parsing the .debug_abbrev section but dumping it showed nothing out of the ordinary(*)
The first hint that the problem was on the LLDB/LLVM side came from llvm-dwarfdump:
error: failed to decompress ‘.debug_aranges’, zlib is not available
error: failed to decompress ‘.debug_info’, zlib is not available
error: failed to decompress ‘.debug_abbrev’, zlib is not available
Sure enough, the sections were compressed. LLDB tried to decompress, but when failed to do so it carried on returning and alter attempting to parse the compressed bytes as is.
Why weren’t my local LLVM & LLDB builds able to decompress the sections? CMake! Apparently the project files didn’t get correctly regenerated and my CMakeCache.txt had an unfortunate set of flags:
HAVE_LIBZ_ZLIB:INTERNAL= (empty, hmm…)
It should have something like this instead:
So there you have it folks. If it doesn’t work, reboot regenerate your cmake projects and try again.
(*) none of the tools bothered to make a note that the sections are compressed (SHF_COMPRESSED)