[PATCH] D39021: [llvm-objcopy] Add support for --only-keep and the special way it interacts with -O binary

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In https://reviews.llvm.org/D39021#913197, @jakehehrlich wrote:

> Can you show me which inputs were not preserving relative offsets of sections within the same segment? I gave up trying to read the code and went back to empirical testing. After getting many more data points my theory about the behavior is the following


Never mind - I apparently failed at maths. I can't reproduce what I saw yesterday, so I'm 99% certain I just calculated the difference wrong.

> The first segment that contains a non-removed section is treated specially for some reason. The first section behaves in the following manner:
> 
> 1. Trailing ** and initial** removed sections of a segment are not copied to the output file.
> 2. Relative offsets of sections with the segment are preserved
> 3. Removed sections are overwritten with zeros if they still have allocated space due to relative offsets being preserved
> 
>   The remaining segments are placed at locations that preserve the segment alignment. Only trailing removed sections seem to be removed in this case.
> 
>   So alignment is trashed if the first section is removed but relative offsets seem to work correctly. In particular If the first section of a segment is never removed then -O binary seems to produce sensible output. Also if alignment is the only thing we sacrifice and we only sacrifice it in the case that the first section is removed then I think this is the most sensible behavior that can exist. It seems to me the following requirements are contradictory and one of them must be dropped
> 4. -O binary -j <some section> should dump the contents of <some section> (without padding before or after)
> 5. alignment of section offsets should be preserved
> 6. relative offsets of sections should be preserved
> 
>   If we drop 3) we can maintain alignment in all but one case and be consistent with GNU objcopy in every case I have thus far found. The only strange behavior we have to add is removing leading zero space from the first segment.

When you talk about relative offsets of sections, are you talking about relative to the segment start? If so, I agree that appears to be the objcopy behaviour, and I'm happy for this to be done in llvm-objcopy. With that change, we should be able to drop the SectionDump class, as the BinaryObject class should give us the functionality we expect for -j, along with the other cases. I think it might be wise to make these changes in a separate pre-requisite review, since it's really a separate issue (e.g. the behaviour we currently have for -R is different to gnu objcopy's, if the first or last section is stripped).


Repository:
  rL LLVM

https://reviews.llvm.org/D39021