[PATCH] D40523: [llvm-objcopy] Add --only-keep-debug

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In https://reviews.llvm.org/D40523#941536, @jakehehrlich wrote:

> So I spoke with Roland McGrath about what should be happening with the program headers and it's kind of strange. Basically they should be kept exactly as is but that shouldn't mean that all that space is consumed because of them which demands a more complex change that I desired. The program headers are sometimes needed to match the contents due to prelink.
>
> This presents a complication because right now segments are always laid out where as in this case we really should just ignore their existence and output them without considering them during layout. It feels a bit hacky but I suppose we can add a boolean flag for "ignore program headers during layout". Honestly the whole behavoir of --only-keep-debug is quite exceptional; it dosn't really like obeying the rules.


I agree that it is all a bit weird. Further investigation suggests that objcopy does the following:

1. All allocatable sections are converted to NOBITS.
2. The size of these sections is left unchanged.
3. The offset of these sections is moved to the start offset of the program headers, before the change.
4. The file size field is the only field of the program headers that changes, with the NOBITS sections no longer contributing to its size, as is normal. The address and offset remains the same.
5. Sections not in segments are moved as normal, i.e. based on the updated segment sizes from before. They may move to before segments, if there is space for them to fit. I assume (but I haven't experimented with this) that they cannot overlap the spot where a segment should be (e.g. if the segment is at offset two, a 2-byte-sized non-alloc section won't appear at offset 1).
6. The output file size does not include segments with their contents stripped.

I get the feeling that none of the above will happen with the current layout scheme... I don't have a good proposal for you at this point, other than to maybe consider a separate layout scheme entirely, that observes the above rules.


Repository:
  rL LLVM

https://reviews.llvm.org/D40523