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

Wed May 27 11:23:20 PDT 2020

MaskRay added a comment.

Reading https://opensource.apple.com/source/cctools/cctools-949.0.1/man/strip.1.auto.html , I confirm that -S -r -D -n are conflicting.

In D80099#2057816 <https://reviews.llvm.org/D80099#2057816>, @alexshap wrote:

> @jyknight, thank you for the comment.
>
> 1. Just to be clear - introducing new names alone will make it incompatible with a huge variety of existing projects / their build systems. If hypothetically you move this burden to the layer of a build system then **users** will have to deal with this issue N times, where N is equal to the number of users or to the number of different build systems (depending on how you count). It would create an unnecessary obstacle and would cause massive duplication of efforts.

How can llvm-strip be plugged into an existing project if -S -r -D -n (supposedly common usage) do not work?

> P.S. llvm-objcopy indeed has reimplemented a number of command-line options of binutils objcopy, 
>  but it also has some extensions (flags which binutils objcopy doesn't support) as well as some omissions (flags which binutils objcopy supports but llvm-objcopy doesn't) so in this respect it doesn't create a new precedent.
>  It's also true for other binary-level tools in LLVM which emulate (to some extent) the interface of their counterparts from other projects.

FWIW For many such extensions I have created feature requests on binutils bugzilla or even implemented the features by myself.
If we are going to add a new long option, I hope we can see efforts asking cctools to adopt. Some option names may potentially be reused with different semantics. If they don't want to implement those features, we can at least get a promise that they will not intentionally use the options names for difference purposes.

For this particular case, -T is a really unfortunate name for a special cased feature. I think we need to persuade them to add a long option.

> 2. The current state of llvm-strip - some projects build successfully if one switches to llvm-strip, though certainly these tools are still under development (and this statement is not specific to MachO) and different features are implemented when they are needed. I'm aware of several ways how people use llvm-objcopy / llvm-strip for MachO.
> 
>   That said, your concern is valid, indeed, in the future the issue which you mentioned may come up (though there is no conflict now, moreover, introducing a new name **would break the existing use-cases**). Given that bintuils strip for MachO is not used (and it's not really fully functional if I am not mistaken) - the most common (and sort of the most realistic) way to use llvm-strip  for MachO is to use it in place of the "system strip" (coming cctools) (on OSX).

Given the -S -r -D -n incompatibility, I think we will run into trouble soon.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80099