fix(elf): apply ELF relocations to debug sections in relocatable objects

[darktorres]

Summary

Unlinked relocatable objects (ET_REL, i.e. plain .o files) leave every DW_FORM_line_strp/DW_FORM_strp offset field in .debug_line/.debug_info as a zero placeholder, with a companion R_*_32/R_*_64 relocation recording the real offset into .debug_line_str/.debug_str (those sections' final layout isn't settled until link time, since they can be merged/deduplicated across translation units). ElfObject::parse already parses these relocations into elf.shdr_relocs, but nothing ever applied them before handing section bytes to gimli, so every such field silently read back as offset 0.

This is usually invisible for DW_AT_comp_dir, since GCC/Clang tend to place comp_dir's string first in these sections (so its unrelocated placeholder and its real relocated offset both happen to be 0), but it corrupts every other directory/file-table entry in a DWARF5 line program's include_directories/file_names tables, and any DW_FORM_strp-encoded attribute in .debug_info more generally. When the wrongly-resolved path happens to coincide with a directory that exists on disk, sentry-cli debug-files bundle-sources / debug-files upload --include-sources hard-errors trying to open it as a file ("Is a directory (os error 21)") instead of resolving -- or gracefully skipping -- the source. When it doesn't, the source is silently attributed to the wrong file, or a source lookup silently fails ("no files found").

Root cause, verified independently

• Instrumented gimli's DWARF5 line-program parser directly: cursor advancement/byte-consumption for every field is exactly correct; the value read for every line_strp/strp field is genuinely 0 in the section bytes handed to it -- verified against readelf -r's dump of the corresponding .rela.debug_line/.rela.debug_info section, which shows the real (non-zero) relocation targets untouched at those exact file offsets.
• readelf, llvm-dwarfdump, and gdb all correctly resolve the exact same bytes (they apply the relocations themselves, as expected for any relocation-aware DWARF consumer). Stripping .rela.debug_line from an otherwise-correct object (objcopy --remove-section=.rela.debug_line) reproduces the identical corruption in readelf's own dump of that same file -- i.e. removing relocation application from a working tool breaks it the same way, confirming this is exactly the missing step rather than a coincidence.
• Reproduced with GCC 13.4.0 and 15.2.0, and Clang 21, across DWARF32 and DWARF64, x86_64 and aarch64, with and without -fno-merge-debug-strings, with plain/split-DWARF (-gsplit-dwarf) and compressed (-gz) debug sections -- same mechanism every time.
• Already-linked objects (ET_EXEC/ET_DYN, including PIE executables, shared libraries, and objcopy --only-keep-debug output) are unaffected, since the linker resolves these relocations itself before symbolic ever sees the bytes.

Fix

After loading (and decompressing) a DWARF section's bytes for a relocatable object, look up any relocations targeting that section from the already-parsed elf.shdr_relocs and patch them into an owned copy before handing the bytes to gimli. Scoped to the R_*_32/R_*_64 "absolute value" relocation types actually used for debug-string offsets on ELF's two most common architectures (x86_64, aarch64); other relocation types are left untouched, matching prior behavior.

Testing

• cargo test -p symbolic-debuginfo --features elf: all suites pass (120 + 49 + 4 + 2 + 10 unit/doc tests, 0 failed).
• cargo clippy -p symbolic-debuginfo --features elf --no-deps: clean.
• cargo fmt -p symbolic-debuginfo -- --check: clean.
• Manually verified end-to-end against a locally-built sentry-cli linked to this patched symbolic-debuginfo: debug-files bundle-sources now produces a correct source bundle (verified manifest + extracted file contents match the real source) for objects that previously hard-errored, with zero regression on already-working linked binaries/shared libraries.

[darktorres]

Good catch — fixed in the latest push. apply_section_relocations now writes the addend in the object's actual byte order (self.elf.little_endian) instead of always assuming little-endian, so it matches what gimli reads back regardless of target endianness. Verified cargo test -p symbolic-debuginfo --features elf still passes (120+48+4+2+10, 0 failed) and clippy/fmt stay clean.

[darktorres]

Re the addend as u64 cast flagged above: this isn't a bug. In Rust, as between two 64-bit integer types (i64 -> u64) is a pure bit-reinterpretation, not a narrowing/lossy conversion -- there's no value to lose. For a -20 addend, addend as u64 gives 0xffffffffffffffec, and the suggested fix (sign-extend through i128 first) gives the exact same 0xffffffffffffffec -- verified with a standalone Rust check, they're byte-for-byte identical. Truncating that to the relocation's width (4 or 8 bytes, little end first) reproduces the correct two's-complement bit pattern for the field either way, which is exactly what's needed here: relocation addends are conceptually raw bits to place in a fixed-width field, and R_*_32/R_*_64 are defined to take the low N bits of the computed value regardless of sign (the same pattern e.g. LLVM's own relocation-writing code uses). Leaving the cast as-is.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a951edc. Configure here.}

[darktorres]

Good catch too — also fixed in the latest push. apply_section_relocations now switches on self.elf.header.e_machine before matching relocation type numbers (only handling EM_X86_64/EM_AARCH64, returning early otherwise), since those type constants are only meaningful per-ABI and do collide across architectures as you noted (e.g. type 1 is R_X86_64_64, R_PPC_ADDR32, and R_RISCV_32). Re-verified against real x86_64 and aarch64 objects (both still produce correct, non-crashing source bundles with correctly-resolved paths) plus cargo test/clippy/fmt, all still clean.

[darktorres]

Pushed a follow-up addressing gaps from my own review after the two bot-caught fixes:

• Added a regression test with a purpose-built unlinked.o fixture (checked in under symbolic-testutils/fixtures/linux/relocations/, with a README documenting exactly how it was generated). Verified it's not a tautology: reverted the fix locally and confirmed the test fails (the fixture's corrupted output happens to still satisfy a weaker ends_with check, so the assertion checks dir_str()/name_str() for exact equality instead), then restored the fix and confirmed it passes.
• Documented the two implicit assumptions: r_addend is used directly as the resolved value (assumes a section-relative relocation symbol, i.e. value 0 -- true for every compiler's debug-section relocations, but not guaranteed by the ELF format), and a REL (non-RELA) relocation section is a safe no-op rather than handled (both x86_64 and AArch64 are RELA-only per their psABIs, so this never currently triggers, but stays a no-op instead of corrupting data if that ever changes).
• Dropped the per-relocation heap allocation -- writes into a fixed [u8; 8] stack buffer and slices it instead of .to_vec().

cargo test -p symbolic-debuginfo --features elf, clippy, and fmt all still clean.

[loewenheim]

Hi, thank you very much for the contribution!

[loewenheim]

Out of interest, how did you hit upon this problem? Are you trying to upload relocatable ELF files to Sentry?

[darktorres]

Hi, I got hit by this issue in this run https://github.com/GIBIS-UNIFESP/wiRedPanda/actions/runs/33291256790/job/99203154905