[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#947252, @jakehehrlich wrote:

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


As long as consumers of this are fine with that, I have no issues either way, although a non-zero relative offset within a segment with file size zero doesn't make much sense (it implies that the section does not sit inside the segment). The relative order of the sections is still controlled by the address fields, which remain unchanged.

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

I think the point of reducing the file size field of the segments is so that they actually do not take up any space in the output file, reducing the overall file size by quite a bit potentially. See below.

>> 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. The output file size does not include segments with their contents stripped.
> 
> I'm confused how this is different from 4. Mind elaborating?

4. deals with the file size field of a segment, and indeed, it's actual size on disk, whereas 6) is to do with the offsets of the segments and the overall object file size. Typically, NOBITS sections do not take up any disk footprint, so zero-sized segments make sense. However, usually a segment will always reside within the bounds of the output file, i.e. p_offset <= file size. In this case however, p_offset might be greater than file size, because the segments are not moved, but also require zero space on disk. objcopy appears to shrink the object to as small as it can, whilst still preserving the remaining non-replaced section contents at the location wherever that may be.


Repository:
  rL LLVM

https://reviews.llvm.org/D40523