This is an archive of the discontinued LLVM Phabricator instance.

ELF GetSectionHeaderInfo: process SHT_NOTE even without .shstrtab
AbandonedPublic

Authored by jankratochvil on Feb 5 2018, 1:44 PM.

Details

Reviewers
labath
Summary

This is written for tha YAML testcase of D42914. Its unstripped.yaml contains:

  Start of section headers:          64 (bytes into file)
  Number of program headers:         0
  Section header string table index: 5
Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 1] .note.gnu.build-id NOTE            0000000000400274 0001c0 000024 00   A  0   0  4
  [ 5] .shstrtab         STRTAB          0000000000000000 000226 000034 00      0   0  1

while there is:

ObjectFile::GetModuleSpecifications:
  DataBufferSP data_sp = DataBufferLLVM::CreateSliceFromPath(file.GetPath(), 512, file_offset);

and so ObjectFileELF::GetSectionHeaderInfo has only 0x200 bytes available to find UUID (=build-id). It could find it if there were either program headers present (obj2yaml does not preserve them) or if .shstrtab was present in the first 512 bytes (which it is not).
But then we do not need .shstrtab as we can identify the note section by its SHT_NOTE, we do not need its name. That's this patch.
It does not have a testcase but D42914 does FAIL for me without this patch on Fedora 27 x86_64.

Diff Detail

Event Timeline

jankratochvil created this revision.Feb 5 2018, 1:44 PM

I see now Pavel has solved it by:

[Lldb-commits] [lldb] r324254 - Fix parsing of object files with "early" section headers
https://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20180205/038992.html

I am not sure if that is not a more general solution but this patch should be faster/cheaper.
build-id's goal is to be at the very beginning of the file to fit into the Linux kernel CORE_DUMP_DEFAULT_ELF_HEADERS dumping of the first page (4096 bytes). I see now some system files have the build-id at offset 0x274 for example so one would have to also change the 512 bytes chunk of ObjectFile::GetModuleSpecifications: to 4096 to make this patch really valid.

labath added a comment.Feb 6 2018, 2:30 AM

As I mentioned in the patch above, I don't think it's worth it trying to tiptoe here, as for 99% of files (basically, anything that is not yaml2obj's output, I think), we will end up reading the whole file anyway. It just increases the number of things that can go wrong.

It might be interesting to make GetModuleSpecifications access only the smallest number of bytes as possible, but for that we should make a larger patch that changes the entire parsing logic.

jankratochvil abandoned this revision.Feb 6 2018, 2:32 AM

I think this patch still makes sense but whatever.