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

[Jake Ehrlich via Phabricator via llvm-commits]

jakehehrlich added a comment.

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

Sorry, I got confused with offset and index here. The behavior I'd like here is for the offset to be set by the existing layout algorithm which will frequently be the top but sometimes will be the bottom and occasionally will be somewhere in the middle depending on how we set segment sizes. In this current patch the size of PT_LOAD segments and their children segments will always be zero so everything will have the same offset (the only offset possible). I agree keeping the original offset doesn't make sense.

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

Right. Roland's claim was that you should just copy the segments and then layout the sections as if the segments didn't matter. Since NOBITS sections don't really need to consider segments to be laid out and non-allocated sections generally are not in segments this is actually quite valid but the program headers become bizarrely special. Also this fails when you have non allocated sections in segments which is something we've supported so far (correctly so I'd say). Roland takes the stance that it isn't clear what would be wrong with changing the filesize but believes that not changing it is certainly correct.

As for this patch. I've slept on it and I'm ok with this going in if you think everything else is in order. Particularly look at how I change segment size BTW as I believe I'm being a bit more aggressive that even GNU objcopy is being (since it appears to keep around RELRO segments where as I am not)


Repository:
  rL LLVM

https://reviews.llvm.org/D40523