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

> On Apr 9, 2018, at 3:23 PM, James Y Knight via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
> 
> I'm not really clear on the actual benefits of the TBD file, and why
Apple migrated to them in the first place. Shouldn't a dynamic library
containing only the relevant parts (e.g. the dynamic symbol table) be roughly
comparable in size? And, much simpler to support? I assume that's
effectively what "Mach-O Dynamic Library Stubs" actually _were_,
before the introduction of TBD files, so presumably there were good reasons for
switching?
File size is one reason. A TBD file is typically one third the size of the
corresponding stub library for a single architecture. Multiple architectures
dramatically increase the TBD advantage: a new architecture in TBD may cost as
little as a few bytes if all architectures export the same functions, but each
new architecture in a stub library requires duplicating its entire contents.


-- 
Greg Parker     gparker at apple.com     Runtime Wrangler

> Regardless of any of that, given that TBD files _are_ an integral 
part of the apple platform, supporting them is certainly a necessity in 
order to have a working apple linker. So, if making LLD work for 
Apple/MachO is the justification for adding TBD support to LLVM, that 
seems self-evidently a reasonable thing to do. On the other hand, it 
looks like the LLD mach-o code is unmaintained and nobody seems to be 
much interested in it. And having code for reading TBD files in 
LLVM seems not terribly interesting, unless it is as part of a project 
to make the LLD MachO linker actually functional and supported.

Yes. I hope this can be reason enough. Hobbyists could push for LLD 
support for Mach-O besides Apple, and if LLD is to displace other 
linkers this is a necessary component as you say. Better to upstream now 
before the code diverges than more work later? Conversely if nothing 
happens, I doubt libtapi would be a greater drag on the codebase than 
the MachO LLD code, so whatever cost/benefit analysis exists for keeping 
that around could also apply to this.

 > On 04/09/2018 06:39 PM, Greg Parker via cfe-dev wrote:

 >> On Apr 9, 2018, at 3:23 PM, James Y Knight via cfe-dev 
<cfe-dev at lists.llvm.org> wrote:

 >> I'm not really clear on the actual benefits of the TBD file, and
why
Apple migrated to them in the first place. Shouldn't a dynamic library 
containing only the relevant parts (e.g. the dynamic symbol table) be 
roughly comparable in size?...

 > File size is one reason...

For the record, other small benefits are

  - The inclusion of the path to the actual library, which as far as I 
know is not something that can be done with a stub library. This allows 
easy absolute or relative (with R(UN)PATH) linking. Comparatively, 
passing the right -rpath and -rpath link is manual and (in my opinion) 
harder to understand and cumbersome, and also not a solution for 
absolute linking. I work with Nixpkgs of NixOS, where absolute path 
linking is frequently an objective as part of a general principle of 
avoiding indirection.

  - YAML. The option for line-oriented structure allows for easy diffing 
with conventional line-based diffing tools, which is useful for 
debugging compatability issues. (e.g. Why did my new version remove 
symbols? Why did my security update change anything at all?). Of course 
one can just objdump and diff, but that wouldn't happen automatically 
with version control, for example.

John

On Mon, Apr 9, 2018 at 10:11 PM, John Ericson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> > Regardless of any of that, given that TBD files _are_ an integral part
> of the apple platform, supporting them is certainly a necessity in order to
> have a working apple linker. So, if making LLD work for Apple/MachO is the
> justification for adding TBD support to LLVM, that seems self-evidently a
> reasonable thing to do. On the other hand, it looks like the LLD mach-o
> code is unmaintained and nobody seems to be much interested in it. And
> having code for reading TBD files in LLVM seems not terribly interesting,
> unless it is as part of a project to make the LLD MachO linker actually
> functional and supported.
>
> Yes. I hope this can be reason enough. Hobbyists could push for LLD
> support for Mach-O besides Apple, and if LLD is to displace other linkers
> this is a necessary component as you say. Better to upstream now before the
> code diverges than more work later? Conversely if nothing happens, I doubt
> libtapi would be a greater drag on the codebase than the MachO LLD code, so
> whatever cost/benefit analysis exists for keeping that around could also
> apply to this.


Speaking for the Zig project here, our goal is to support cross-compilation
for any target, on any target, without requiring installation of any
target-specific SDK. So, for example, these use cases:
 * on linux, compile & link a binary targeting macos
 * on windows, compile & link a binary targeting macos

This works today, although it depends on a patch to LLD to fix the MACH-O
linker that is not high enough quality to upstream.

So we have a vested interest in improving the MACH-O linker, and in fact a
Zig community member has fixed at least one bug in MACH-O LLD:
reviews.llvm.org/D35387

I don't fully understand how TBD or TAPI works, but I hope that it results
in improvements to the MACH-O linker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180410/8d503873/attachment.html>