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

Alexander Shaposhnikov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed May 27 10:50:30 PDT 2020


alexshap added a comment.

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

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.

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 what was mentioned in (1) renaming (or renaming alone) doesn't appear to the right solution.

As soon as we run into this issue - **no doubt**, a solution will need to be implemented. The current state doesn't appear to block it or prevent it in any way, moreover, it enables us to move step by step 
and there are multiple ways to solve this problem. 
"If, in the future, someone wants to make another command which is a drop-in-replacement for cctools strip, that could be done, and it will need to do option-translation" - this is essentially one of the options mentioned above, though the details require more thinking.
Let me point out that  llvm-strip is also just another driver for llvm-objcopy (it was introduced here: https://reviews.llvm.org/rL331663), 
all what it does - it translates options and invokes llvm-objcopy).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80099





More information about the llvm-commits mailing list