gimli should support supplementary object files

[philipc]

Fixing the gimli-symbolize feature to handle supplementary object files shouldn't be a lot of effort:

• gimli already supports them (dwarfdump: add --sup option gimli-rs/gimli#552)
• addr2line will need updating to read the units from the supplementary object file, and handle references to entries in it when looking up names (Handle supplementary object files gimli-rs/addr2line#208)
• backtrace-rs will need to read the .gnu_debugaltlink section to find and load the supplementary object file

Also, backtrace-rs doesn't currently follow .gnu_debuglink or NT_GNU_BUILD_ID with the gimli-symbolize feature. I assume that one or both of those are needed too.

[philipc]

@cuviper Since libbacktrace support in this crate is being removed (#423), we'll need to fix this issue rather than #409. I've started looking at what is required, but I'm not familiar with Fedora, so maybe you can help me out with some information.

I'm using Fedora 34 in a container. My initial goal is to write some Rust code that does a backtrace that relies on correct parsing of Fedora's supplementary object files. Unless you have a better suggestion, I think I need to find a C library that I can pass a Rust callback to, and for which Fedora has packaged the debuginfo using dwz with the -m option. Can you suggest something for that?

I was hoping libc would work, but it doesn't appear to use a .gnu_debugaltlink. And kind of related, the build id for libc doesn't make sense to me. Why does the debug link point back to the library instead of to /usr/lib/debug/lib64/libc-2.33.so.debug? I realize I can use .gnu_debuglink instead, so not a problem for me, just something I don't understand.

$ readelf -n /usr/lib64/libc-2.33.so
Displaying notes found in: .note.gnu.build-id
  Owner                Data size        Description
  GNU                  0x00000014       NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: 6e3c087aca9b39549e4ba92c451f1e399b586e28

$ readlink -f /usr/lib/debug/.build-id/6e/3c087aca9b39549e4ba92c451f1e399b586e28
/usr/lib64/libc-2.33.so

[cuviper]

I was hoping libc would work, but it doesn't appear to use a .gnu_debugaltlink.

Some builds don't use dwz for some heuristic reasons -- often due to size, ironically -- but I think glibc has customized their entire debuginfo flow. You could use libdnf as an example for a relatively small library that does have .gnu_debugaltlink.

Why does the debug link point back to the library instead of to /usr/lib/debug/lib64/libc-2.33.so.debug?

$ readlink -f /usr/lib/debug/.build-id/6e/3c087aca9b39549e4ba92c451f1e399b586e28
/usr/lib64/libc-2.33.so

There is a second link $ID.debug for the split debuginfo file.

$ readlink -vf /usr/lib/debug/.build-id/6e/3c087aca9b39549e4ba92c451f1e399b586e28.debug
/usr/lib/debug/usr/lib64/libc-2.33.so.debug

Tangentially, while we're talking about Fedora features, it would be really nice to see support for .gnu_debugdata, which contains compressed symbol tables. For example, the elfutils command eu-readelf --elf-section -s file... can read this.
https://fedoraproject.org/wiki/Features/MiniDebugInfo
https://sourceware.org/gdb/onlinedocs/gdb/MiniDebugInfo.html