Unstripped elf files generate symbol-only index
- Dominant language
- C++
- Stars
- 1.3k
- Forks
- 404
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 38
Description
Currently, `ELFFileKeyGenerator.GetKeys` generates the `elf-buildid-sym-` prefixed key for ELF unstripped binaries. According to the [SSQP entry on elf images](https://github.com/dotnet/symstore/blob/main/docs/specs/SSQP_Key_Conventions.md),
> 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.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.