Failing to parse Firefox libxul.so .debug_aranges due to unexpected version 3 in aranges header
mstange opened this issue · comments
Steps to reproduce:
- Download https://symbols.mozilla.org/libxul.so/99DCE71F78C5366B1745C50AB185EF100/libxul.so.dbg.gz and decompress it.
- Try to use gimli/addr2line to look up file and line information for an address.
Expected results:
The information should be found.
Actual results:
Gimli returns UnknownVersion(3) when iterating over the address ranges headers.
Using llvm-dwarfdump --debug-aranges libxul.so.dbg confirms that some of the headers use version 3. The DWARF 5 spec says that the version is always 2.
Output from llvm-dwarfdump: https://gist.github.com/mstange/c580559ef4ad593aca8f6b299af53e6e
Is this the presence of these version 3 headers a bug?
Would it be acceptable to relax the version check?
I found the following pieces of llvm code:
- This code in
llvm/lib/MC/MCDwarf.cppwhich always writes version 2. - This code in
llvm/lib/DebugInfo/DWARF/DWARFDebugArangeSet.cppwhich accepts arbitrary versions during parsing. - This code in
lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cppwhich accepts versions 2 to 5 during parsing.
With a relaxed version check, addr2line outputs the correct information.
% cargo run --release --example addr2line -- --exe ~/libxul.so.dbg -pCfi 0x5a7dcee
glsl::VertexShaderImpl::run_primitive(char*, unsigned long) at /build/firefox-26DV6q/firefox-89.0+build2/gfx/wr/swgl/src/program.h:72
(inlined by) draw_quad(int, Texture&, Texture&) at /build/firefox-26DV6q/firefox-89.0+build2/gfx/wr/swgl/src/rasterize.h:1522
Alternatively, addr2line could ignore information from aranges if parsing aranges fails. It has other sources of range information.
Similarly, symbolic-debuginfo has no problems with this libxul.so file because it doesn't make use of aranges.
Looks like a NASM bug fixed in netwide-assembler/nasm@29a61b7
Nice find!