bitcode_strip is a utility which is used to manipulate (leave / remove)
bitcode segments in a Mach-O file. It is a part of Apple’s cctools and it is also distributed with Xcode.
The man page of the tool is available here https://www.manpagez.com/man/1/bitcode_strip/.
The functionality of bitcode_strip naturally maps onto llvm-objcopy’s model and requires only minimal additions to it.
Therefore, similarly to llvm-strip and llvm-install-name-tool we propose adding a new driver to llvm-objcopy (for Mach-O) with the goal to make it a drop-in replacement for cctools’ bitcode_strip. Among other benefits this approach enables us to save space in toolchain distributions (no extra binaries added) and reuse some llvm-objcopy’s features.
We already have llvm-lipo, llvm-install-name-tool, llvm-strip, llvm-libtool-darwin and llvm-bitcode-strip appears to be one of the last missing tools commonly used for Mach-O.
Any feedback / comments / suggestions would be greatly appreciated.
No issues from me in adding it, though I don’t know anything about the tool itself. Would it make sense to integrate this fully into llvm-strip’s interface (so that llvm-strip can do strip and bitcode_strip things by default)? Are the two sufficiently compatible? You could then have a bitcode_strip symlink when creating cctools symlinks, much like there exists already for the other tools.
Yeah, this is a very reasonable question.
I’ve looked at
there is a conflict of the command line options - e.g. on OSX they both have “-r”
(https://www.unix.com/man-page/osx/1/strip/ , https://www.manpagez.com/man/1/bitcode_strip/) and the semantics are completely different.
Some functionality (e.g. “-l”) of bitcode_strip appears to be out of place for
strip, thus it seems like having a separate driver would be a cleaner solution.
Regarding the symlinks structure - right, the plan is to create a new symlink to llvm-objcopy (similarly to llvm-strip which is a symlink as well)
and if it’s invoked as
bitcode_strip we will parse the command line arguments accordingly.
Makes sense, thanks. +1 from me for the principle.