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

[James Y Knight via llvm-dev]

On Tue, Apr 10, 2018 at 5:33 PM Jake Ehrlich via llvm-dev <
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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180411/b9064b3c/attachment.html>