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

[Jake Ehrlich via Phabricator via llvm-commits]

jakehehrlich added a comment.

In https://reviews.llvm.org/D40523#941757, @jhenderson wrote:

> 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.


Done and agreed.

> 3. The offset of these sections is moved to the start offset of the program headers, before the change.

I don't think there's any terribly good reason to do this honestly. I'd rather keep their index if possible.

> 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.

This is tricky. I'm going to upload some code that changes the file size accordingly but please don't bother approving it as a) it's subject to change and b) I'm not sure it's right or that I understand all the moving parts here.

> 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).

Yeah I think this is right and this property would hold right now (but the segments wouldn't be any smaller, they would just take up lots of space).

> 6. The output file size does not include segments with their contents stripped.

I'm confused how this is different from 4. Mind elaborating?


Repository:
  rL LLVM

https://reviews.llvm.org/D40523