Alexander Shaposhnikov via llvm-dev
2020-Aug-21 04:03 UTC
[llvm-dev] RFC: Contributing bitcode_strip
*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. Kind regards, Alexander Shaposhnikov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/c0bd7ef4/attachment.html>
James Henderson via llvm-dev
2020-Aug-21 10:04 UTC
[llvm-dev] RFC: Contributing bitcode_strip
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. On Fri, 21 Aug 2020 at 05:03, Alexander Shaposhnikov via llvm-dev < llvm-dev at lists.llvm.org> wrote:> *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. > > Kind regards, > Alexander Shaposhnikov > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200821/733b667f/attachment.html>
Alexander Shaposhnikov via llvm-dev
2020-Aug-21 19:29 UTC
[llvm-dev] RFC: Contributing bitcode_strip
Yeah, this is a very reasonable question. I've looked at `strip` and `bitcode_strip`, 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. Kind regards, Alexander Shaposhnikov On Fri, Aug 21, 2020 at 3:04 AM James Henderson < jh7370.2008 at my.bristol.ac.uk> wrote:> 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. > > On Fri, 21 Aug 2020 at 05:03, Alexander Shaposhnikov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> *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. >> >> Kind regards, >> Alexander Shaposhnikov >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200821/8d3fc2de/attachment.html>