[PATCH] D39769: [llvm-objcopy] Add --strip-all option to remove all non-allocated sections but keep section header table

[Jake Ehrlich via Phabricator via llvm-commits]

jakehehrlich added a comment.

So I'm wondering if we should be following what GNU objcopy does here. After talking with Roland for a bit I'm back to thinking that removing non-allocated sections is the way to go. What I think we want --strip-all to do is minimize the size of a fully linked executable while maintaining any relevant section headers of the content still in the file. For instance I want .dyn* sections to be kept so that I can run --strip-all on shared objects and still link against them. In general I'm not sure we should be mimicking what GNU objcopy does just for the sake of doing what GNU objcopy does as long as the feature in question is attached with some understandable intent. I think --strip-all has just such an intent; namely it should be used when you want to reduce the size of a fully linked object but you don't want to change what can be done with the object with the exception of debugging.

The goal of --strip-all is to reduce the size while maintaining different degrees of functionality and --strip-all feels some position in this trade off between functionality and size. Here's how I see the intent of various options

--strip-sections -> Any information not needed for loading should be removed
--strip-all -> (Unsure but loadability should be preserved, the section headers should be preserved for content still in the file, and a shared object should still be linkable against)
--strip-debug -> Any information only needed by the debugger should be removed.
--strip-uneeded -> This one is actually very precisely defined unlike the rest. You should remove all symbols not needed for relocation.

Roland McGrath pointed out to me that .gnu.warning.* sections should probably be kept by --strip-all. Roland seems to think that at least at first removing non-allocated sections and then selectively keeping certain special sections (like .gnu.warning.*) would be a better way to go than what GNU objcopy does.



================
Comment at: tools/llvm-objcopy/llvm-objcopy.cpp:177
+      if ((Sec.Flags & SHF_ALLOC) != 0)
+        return false;
+      if (&Sec == Obj->getSectionHeaderStrTab())
----------------
jhenderson wrote:
> Won't this and the next "return false" override any other "RemovePred" specified earlier? They should probably be "return RemovePred(Sec)" or similar, otherwise you can't do "--strip-all --remove-section=.text" or similar.
Yea this is a problem. This is not a consistent way to behave.

There's a general problem here of how we should resolve disagreements between predicates. So a predicate should have 3 stances on the removal of a section a) remove b) keep or c) don't care. option c) can't cause a contradiction but a) and b) can conflict if used. We could take a general stance and say that only a) and c) are allowed then rather than returning "false" in any given case we just return the result of the previous RemovePred. That actually sounds the most sensible to me. Order of arguments wouldn't matter if we adopt that stance. For sections there are not "but keep this" operations so removals should compose I think.

The only other option I can see is to make order matter and to process the options by their order. I'm generally in favor of order not mattering however so I think I should replace any "return false" with "return RemovePred(...)" instead. I don't really strongly hold that opinion however so I would be happy doing things in a specific order as well. This code as it stands is order agnostic but resolves contradictions in a specific and bad way. It should either a) now have flags that contradict each other or b) allow later flags to overrule earlier flags. I'm in favor of a) unless GNU objcopy does b)


Repository:
  rL LLVM

https://reviews.llvm.org/D39769