[PATCH] D42872: Fix handling of zero-size segments in llvm-objcopy

[vit9696 via Phabricator via llvm-commits]

vit9696 updated this revision to Diff 134055.
vit9696 added a comment.

Well, I found some time to prototype what we discussed. As I got to the code I think I discovered more hidden issues that were not taken into account, and mentioned them as the comments in the code.

I used the following spec to base my thoughts on: http://www.skyfree.org/linux/references/ELF_Format.pdf

1. The spec does not seem to define loadable segment alignment to be equal to the page size but only recommends doing that:

  To obtain this efficiency in practice, executable and shared object files must have segment images whose file offsets and virtual addresses are congruent, modulo the page size.

I personally saw files with different loadable segment alignment values, in particular some segments had 4K and some other segments had 16K. I have never seen files where loadable segments had p_align less than page size, so for now I made an assumption that the lowest p_align value in PT_LOAD segments that is not 0 or 1, is no less than the page size.

2. Next it appears that the spec does not guarantee us anything about program header table offset and size. So far I have never seen an ELF which program header table does not follow the ELF header, but the spec explicitly mentions that this is not a requirement:

  Although the figure shows the program header table immediately after the ELF header, and the section header table following the sections, actual files may differ. Moreover, sections and segments have no specified order. Only the ELF header has a fixed position in the file.

This puts us to an uneasy situation, where we definitely know that the file starts with an ELF header, which is likely padded to the page size at least (if we assume that all the ELF files follow the optimisation suggestions from the spec), but other than that we can hardly make any assumptions.

Other than what I have already done I could imagine checking if the program header table overlaps with the first page.
If it does, we should ensure that the dummy segment includes the whole program header table.
If it does not, we should allocate another dummy segment for the program header table. Although I am even less sure of its size size and alignment in this case.

By the way, does llvm-objcopy support big endian ELFs on little endian host?


Repository:
  rL LLVM

https://reviews.llvm.org/D42872

Files:
  test/tools/llvm-objcopy/marker-segment.test
  tools/llvm-objcopy/Object.cpp
  tools/llvm-objcopy/Object.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D42872.134055.patch
Type: text/x-patch
Size: 7581 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180213/1c42ba2e/attachment.bin>