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

James Henderson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 9 04:37:47 PST 2018


jhenderson added a comment.

In https://reviews.llvm.org/D42872#1002886, @vit9696 wrote:

> I think I could have missed the point of the description a little, but I know of at least a total of 3 cases regarding ELF header:
>
> - ELF header is present in PT_LOAD segment
> - ELF header is mentioned in PT_PHDR segment
> - ELF header is not mentioned or present anywhere, but the segment data starts at a random offset the linker decided to use.
>
>   The file I have is the third case, and I think there is no way to find the real size of ELF header (and properly skip it) without iterating over the segments and finding the lowest Offset segment which FileSize is not zero. Correct me if I am wrong, but I do not see how the suggested approach gets around it.


The ELF Header has a defined size, based on whether 32-bit or 64-bit ELF is used, so a pseudo-segment (i.e. not one corresponding to the real one) could be created to cover it. The Program Header table's size and offset can be determined from the ELF Header's fields, so another pseudo-segment could be created to cover it. No special case handling would be needed after that, apart from to throw away these two segments at the end. This approach would work, regardless of whether the ELF Header and Program Headers are nested inside another segment.

> I am not too opposed to writing a slightly larger patch, but I'd rather not do it in a wrong way, and due to the lack of proper ELF format format definitions it is very easy to.

Do you have a specific concern here that we can help with?

> If you are fine with the iteration & a FileSize check I should be able to update the patch with these changes in the reasonable future.

If we want a small patch first, I'd prefer to replace the check with a segment type check rather than a FileSize check, due to previously stated reasons.


Repository:
  rL LLVM

https://reviews.llvm.org/D42872





More information about the llvm-commits mailing list