My earlier statement about wrapping things in a native object file held in that it is controversial. It appears to be still central to your design.
It may help to look at the problem from a different viewpoint: LLVM is not a compiler. It is a framework that can be used to make compiler-like tools.
From that view, it no longer makes sense to discuss "the plugin," or gold, or $AR, because there isn't just one of any of those things. ld64 isn't the only outlier linker to consider. We have our own linker at Sony, for example. From this perspective, then it makes more sense to consider replacing the binary utilities with ones that support bitcode, because from a user-perspective, all of the linkers already transparently support bitcode directly today, as do ar, nm, etc. This has been necessary for the regular LTO process.
It's true that the LLVM versions of these tools support bitcode
transparently, but not all build systems use LLVM versions of these
tools, particularly build systems that support a variety of compilers,
or legacy build systems. And not all build systems have the plugin or
currently pass it to the native tools that can take a plugin for
handling bitcode. In those cases the bitcode support is not
transparently available, and our aim is to reduce the friction as much
as possible. And not all use LTO currently (I know we don't due to the
scalability issues we're trying to address with this design), and in
those cases the migration to bitcode-aware tools and plugins was not
For Sony's linker, are you using the gold plugin or libLTO interfaces?
If the latter, I suppose some ThinLTO handling would have to be added
to your linker (e.g. to invoke the LLVM hooks to write the stage-2
combined function map and either launch the backend processes in
parallel or write out a make or other build file). The current support
for reading native object wrapped bitcode is baked into IRObjectFile
so presumably the Sony linker can handle these native object wrapped
bitcode files if it uses libLTO. We would similarly embed the handling
of the function index/summary behind an API that can handle either so
it is similarly transparent to the linkers. Let me know if there would
be additional issues that make wrapped bitcode more difficult in your
case, or how we could make ThinLTO usage simpler for you in general.
The only tool in the list of tools you mentioned that do not support bitcode directly is objcopy, and that's because nobody has yet written an LLVM-project implementation of it. Personally, I'd much rather you focus on making ThinLTO work by extending bitcode as needed, and we work as a community toward replacing objcopy with an LLVM-native one. It's a big missing piece of the LLVM project today and could be so much better if we could use it to replace Apple's lipo and possibly other extant object file modification tools. (Has anyone surveyed this area?)
That older toolchains have tried to slip non-object file data through the binary utilities isn't really proof that this is a good choice. It might simply reflect the realities of those engineering teams. I wasn't at Sun for this, but DTrace needed a linker feature that apparently the Sun linker team was unwilling or unable to provide, so dtrace(1) gained the ability to modify ELF files directly as needed. That doesn't prove that DTrace's USDT feature shouldn't have been implemented in the linker (as ld64 does directly for Apple), does it?
I'd argue that the realities being addressed by using native object
format in those cases still exist.
If in the end using native object-wrapped bitcode is the best solution, so be it. However, I think it is largely orthogonal to ThinLTO's needs for transporting symtab data alongside the existing bitcode format.
That's certainly true, ThinLTO can be implemented using either format,
and bitcode only support can certainly be implemented. It is a matter
of prioritizing which format to implement first. I had added some
description to the updated RFC on how the function index/summary can
be represented, etc in bitcode. Prioritizing the native object format
doesn't make it easier to implement ThinLTO, but should make it easier