[PATCH] D80099: [llvm-objcopy][MachO] Add support for removing Swift symbols

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

I don't have a good solution to the conflict here, but I want to summarise some of the options we have, with a brief summary of the pros and cons of each. This is duplicating some of what is above, but will hopefully help frame my own and possibly others thinking:

1. Add a long option instead of a short option. Pros: simple, shouldn't be incompatible with a future GNU option abbreviation. Cons: Incompatible with cctools strip, making it impossible to just drop it in as a replacement for that tool for usages that otherwise would work (i.e. which don't use other incompatible options).
2. Add a long option and a short option. Pros: provides a migration path for users who want to adopt llvm-strip instead of cctools trip; provides a possible future alternative in the event that GNU use `-T` for something else. We'd probably want to remove our alias, which would break some people's builds, but at least they'd have an alternative without changing away from using llvm-strip. Cons: people might start using -T when they should use the long option. This could be somewhat mitigated with documentation/warnings etc, but perhaps this is suboptimal. Also doesn't allow people to smoothly migrate if we have to remove the short option in the future. Also we'd have to have some sort of delay between removing the short option and reinstating it with the new meaning to prevent a silent behaviour change. This throws up questions like "how long a delay", so probably isn't ideal.
3. Have a different cctools-compatible front-end for llvm-strip. Pros: allows users of cctools strip to migrate. Cons: requires more maintenance (more tablegen options etc to maintain); wouldn't work as a system linker using the current determined-by-filename approach (currently the file name drives whether the tool is llvm-objcopy or llvm-strip and we already say "if name contains strip, treat as llvm-strip", so can't overload it with "treat as cctools strip").
4. Have a different option (e.g. --macho) that controls the behaviour of option parsing. Pros: allows us to treat options differently depending on the presence of the switch. Cons: doesn't allow for immediate drop-in replacement.
5. New idea: change behaviour based on host OS, similar to llvm-ar behaviour and llvm-cxxfilt --strip-underscore. Pros: allows drop-in replacement on Mach-O based systems; has some precendent in the other tools. Cons: doesn't allow for cross testing easily (i.e. would require something like --macho too); could be a little confusing to future users.

I just came up with it, but I like 5). I think it would satisfy most, possibly all of our requirements, has existing precedent in our other tools, and poses a low risk of future incompatibility. What do others think?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80099/new/

https://reviews.llvm.org/D80099