[PATCH] D39021: [llvm-objcopy] Add support for --only-keep and the special way it interacts with -O binary

[Jake Ehrlich via Phabricator via llvm-commits]

jakehehrlich added a comment.

Ok the following behavior seems consistent with my testing. There are 3 things that can happen to a section (and a 4th default thing sort of)

- Explicit remove
- Explicit copy
- Implicit remove

Implicit copy is an obvious 4th missing part and it's what happens by default but no option has the effect of making this occur.

GNU objcopy throws an error anytime you explicitly remove a section AND explicitly copy that section. The following behavoirs appear to be true

1. No option implicitly copies a section (it's not a possible operation) so if a section is implicitly removed another option can't contradict that (so only explicit contradictions can occur). Implicit removals will never cause errors.
2. -j explicitly copies the named section (or named sections in the case of patterns) and implicitly removes all other sections
3. -R explicitly removes sections
4. Faced with a contradiction between an implicit and an explicit remove/copy you do the explicit one.
5. Faced with an explicit-explicit contradiction you throw an error
6. stripping options are some how magical and ignore these rules above and simply remove what they want to (e.g. they don't respect explicit copies and no errors are thrown)

I propose that llvm-objcopy behave in the following manner:

1. -R explicitly removes sections
2. -j explicitly copies sections and implicitly removes all other sections
3. we add a -keep that explicitly copies a section (the reason this doesn't exist in objcopy is because stripping doesn't respect explicit copies)
4. we should resolve implicit-explicit contradictions the same way
5. we should resolve explicit-explicit contradictions by copying *not* by throwing an error.
6. striping operations should implicitly remove sections

This is still a drop in replacement for objcopy because if you used -j and a stripping option in conjunction in a way that was a contradiction with GNU objcopy you get out a basically empty file. So we're strictly making objcopy more sensible be behaving 6 behave this way.  Both GNU objcopy and my proposed behavior for llvm-objcopy have order invariance which is nice.

I feel strongly about 6. What GNU objcopy does there makes very little sense to me and copying what they do can't possibly help anyone. Additionally I can imagine it might be helpful to implement one of the more extreme stripping options but keep just what you need. For instance --strip-non-alloc -keep .gnu.warning or --strip-non-alloc -keep .comment etc... etc... is a generically useful thing to be able to do and not something you can do with GNU objcopy (GNU objcopy isn't very aggressive in stripping though so it gets away with that).

I could budge on point 5 and throw an error in that case. I just think a) not throwing an error is much easier, b) it doesn't break anyone and c) very little is gained by throwing an error. If we don't check for explicit explicit contradictions we just have to be a bit careful about the order we check the arguments.

How does this sound?


Repository:
  rL LLVM

https://reviews.llvm.org/D39021