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

[Jake Ehrlich via cfe-dev]

I fully agree TBD files will need to be format specific. Producing stubs
(from full shared objects or text) is important and should have a tool to
do it properly. Right now that's an artislian process unique to each
project. Adding linker support is a whole other issue and not one I'm too
concerned with. If someone wants to propose that later, they can. I
certainly won't be proposing it.

As an aside I'm actually quite aware of demand for a textual
representation. I work on a team producing an operating system and we care
about what symbols expose in our system libraries. I also know that lots of
people use libabigail for this sorts of reasons. The demand for human ABI
review exists. Weather a textual representation is important or not is I
suppose unclear.

On Wed, Apr 11, 2018, 8:53 AM James Y Knight <jyknight at google.com> wrote:

> 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/cfe-dev/attachments/20180411/8a48f96d/attachment.html>