Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unstripped elf files generate symbol-only index #4628

Open
hoyosjs opened this issue Jul 18, 2023 · 0 comments
Open

Unstripped elf files generate symbol-only index #4628

hoyosjs opened this issue Jul 18, 2023 · 0 comments
Labels
Milestone

Comments

@hoyosjs
Copy link
Member

hoyosjs commented Jul 18, 2023

Currently, ELFFileKeyGenerator.GetKeys generates the elf-buildid-sym- prefixed key for ELF unstripped binaries. According to the SSQP entry on elf images,

The ELF format files indexed with the ELF-buildid suffix are expected to be the exact image that is loaded in a process or core dump, doesn’t require the module to be stripped of its symbols (although it usually is), and commonly uses the .so suffix or no suffix.

while:

The ELF format files indexed with the ELF-buildid-sym suffix are the result of the stripping process and contain only the symbols from the ELF-buildid indexed module.

That means, a correct implementation should only output elf-buildid- keys. However, we assume anything that has a .debug_info section is assumed to be a symbol file.

https://github.com/dotnet/symstore/blob/1b21c9fb177156a4d9a011f061829ce800490931/src/Microsoft.SymbolStore/KeyGenerators/ELFFileKeyGenerator.cs#L66

We should really be checking for the existence of sections like .symtab to tell if an elf is stripped, .debug_info for presence of symbols, and look at the existence of text.

Workarounds

Stripping the symbols from the binary and indexing both separately is common practice since the binary deployment size decreases. The index gets generated correctly in such scenarios. The simplest way of achieving this is:

objcopy --only-keep-debug foo foo.dbg
objcopy --strip-debug --strip-unneeded foo
objcopy --add-gnu-debuglink=foo.dbg foo

Fix compatibility breaks

Prior uploads using keys generated by the old system are going to be an issue since those files would become inaccessible. The advantage is that the unstripped binary has symbols so there's no reason to try to look for it. However, finding the module is impossible, and we can't reliably tell if it's an unstripped binary from dumps. Hence implementations tend to always look for the module first and the incorrectly indexed symbols are not likely to be accessed.

It feels like a reasonable break to generate only the identity key in that case.

@mikem8361 mikem8361 transferred this issue from dotnet/symstore Apr 23, 2024
@tommcdon tommcdon added this to the Future milestone Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants