[llvm-dev] [cfe-dev] [RFC] Open sourcing and contributing TAPI back to the LLVM community

[John McCall via llvm-dev]

> On Apr 11, 2018, at 11:52 AM, James Y Knight via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> 
> 
> On Tue, Apr 10, 2018 at 5:33 PM Jake Ehrlich via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Benifits of TBD:
> 1) It's human readable and diffs on TBDs correspond to changes in the ABI. Diffs can be automatically added to review processes to ensure that changes to the ABI are reviewed. The TBDs also document your precise ABI.
> 2) The size is smaller which means they can be shipped in an SDK instead of binaries to reduce the size of an SDK
> 
> I'm still skeptical that this is significant.

For Apple it certainly is, mostly because TBDs can support multiple architectures in a much more efficient way than fat images do.  Apple has a lot of architecture/SDK variants with a lot of redundancy between what libraries export on different platforms.

John.

> 
> 3) Stubs are producible from TBDs (or should be) which means stubs for linking can be produced even if we don't directly support them in LLD. This lets you ship the smaller TBD files in place of larger binaries and still link things without direct linker support (assuming you already ship a toolchain with your SDK or expect your users to have this tool)
> 
> Since stubs are producible from TBDs I don't really see a downside. I think we need both, I was going to propose a yaml based representation for ELF for the above reasons anyhow.
> 
> Yea, a tool which can produce a .so from a textual description is certainly much less concerning than adding linker support for a new textual description format. If it's an official linker-supported format, it'd be yet another format that potentially needs to be standardized across multiple linkers, and kept compatible for"ever", etc. I just don't think that seems worthwhile for ELF.
> 
> OTOH, a standalone tool which can convert from a "full" shared-object to an interface shared-object would be _great_ to have. If that tool also has some auxiliary textual I/O format it supports, I guess that's fine, too. (We do have some existing yaml <-> ELF support, via the "obj2yaml" and "yaml2obj" tools.)
> 
> I'd note that reproducing all the things that are required/used from an ELF shared object during linking -- symbol type, binding-type, visibility, version, alignment (!), .gnu.warning messages, various important "SHT_NOTE" sections, and whatever other things I've forgotten about, will need to be a _significantly_ different format than what Apple has as their "TBD" format. Apple's format also has a bunch of special cases in it to make it easier to use for their platform, but a rather less generic tool. E.g., symbols starting with "_OBJC_CLASS_$" are recorded in the "objc-classes" field with the prefix removed, instead of just recording it as-is.
> 
> So, I'd also caution that while the project of "import apple's libtapi into LLVM for LLD/MachO" and "Make a scheme to do interface shared-libs for ELF" might seem superficially related, I'd be very surprised if that actually ended up being the case. I would really not expect it to share just about anything at all other than the concept of being a textual description for a library.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180414/4f426eb9/attachment.html>