You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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.
The text was updated successfully, but these errors were encountered:
Currently,
ELFFileKeyGenerator.GetKeys
generates theelf-buildid-sym-
prefixed key for ELF unstripped binaries. According to the SSQP entry on elf images,while:
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:
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.
The text was updated successfully, but these errors were encountered: