<div dir="ltr">On Thu, Sep 7, 2017 at 6:52 PM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Sep 7, 2017 at 5:01 PM, Juergen Ributzka via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Hi @ll,<br>
><br>
> Over the past years I have been looking into how to reduce the size of the<br>
> SDK that ships with Xcode and how to improve build times for the overall OS<br>
> inside Apple. The result is a tool called TAPI, which is used at Apple for<br>
> all things related to text-based dynamic library files (.tbd).<br>
><br>
> What are text-based dynamic library files?<br>
> Text-based dynamic library files (TBDs) are a textual representation of the<br>
> information in a dynamic library / shared library that is required by the<br>
> static linker - basically a symbol list of the exported symbols.<br>
><br>
> Apple’s SDKs originally used Mach-O Dynamic Library Stubs. Mach-O Dynamic<br>
> Library Stubs are dynamic library files, but with all the text and data<br>
> stripped out. TBD files were introduced to replaced Mach-O Dynamic Library<br>
> Stub files in the SDK to further reduce its overall size.<br>
><br>
> Over time the TAPI tool has grown and is used now in a variety of ways.<br>
><br>
> Dynamic Library Stubbing:<br>
> As mentioned above, TAPI is used to read the content of dynamic library /<br>
> shared library and generates a textual representation that can be used by<br>
> the static linker. The current implementation reads MachO files, but it<br>
> could be extended to also provide the same functionality for other object<br>
> file formats.<br>
><br>
> Framework / Dynamic Library Verification:<br>
> The symbols that are exported from a dynamic library should ideally match,<br>
> or at least contain, all the API that is specified in the associated header<br>
> files. TAPI performs this verification by parsing the header files with<br>
> CLANG and compare the findings to the exported symbols from the library.<br>
><br>
> InstallAPI:<br>
> InstallAPI is a new build phase that generates the TBD file from header<br>
> files only. This allows a dependency of the library to build concurrently<br>
> even before the library has been built itself. This can be used to increase<br>
> parallelism in the build or larger projects or operating systems.<br>
><br>
> Misc:<br>
> - display and operate on TBD files<br>
> - automatically generate API tests from header files<br>
> - libtapi, which is used by the linker (ld64) to parse the TBD files<br>
><br>
<br>
</div></div>I'm interested in whether you plan to have this integrated in lld as well.<br>
As far as I understand, this is going to be the de-facto way of<br>
shipping for Mach-O binaries (at least, the ones released by Apple).<br>
Please correct me if I'm wrong.<br></blockquote><div><br></div><div>Yes, this is already the de-facto way of shipping Mach-O files in the SDK. That means self-hosting LLD against the SDK is currently not possible. The system itself is obviously still shipping full Mach-O files in /System, so you should be still able to self-host against those file.</div><div><br></div><div>My plan is to integrate support for TBD files into all LLVM tools where it makes sense (including LLD). This is why I wanted to start to put the basic support into LLVM first, so it can be used by other tools and libraries.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I tried to self-host lld on El Capitan and it fails because lld<br>
doesn't really know about TBD files.<br>
This, unfortunately, makes the linker not really usable for modern Mac<br>
OS releases.<br>
<span class=""><br>
><br>
> The functionality of the tool is currently limited to Mach-O object files,<br>
> but that is not a technical limitation. In making the tool open source I<br>
> hope others will be able to take advantage of it too and extend its<br>
> functionality to other object file formats.<br>
><br>
><br>
> I initially developed the project as a CLANG project, but that was mostly<br>
> for practical reasons (out-of-tree development, separate repo, etc). For the<br>
> curious ones I pushed the repo to github (<a href="https://github.com/ributzka/tapi" rel="noreferrer" target="_blank">https://github.com/ributzka/<wbr>tapi</a>).<br>
><br>
> I imagine, for example, that the reading/writing of TBD files is something<br>
> that would fit better into the LLVM sources, which makes it available to<br>
> other libraries and tools (e.g. LLVMObject, llvm-nm, lld, ...).<br>
><br>
> I created a small patch that integrates it with llvm-nm and LLVMObject. This<br>
> patch is not complete and I will split it up into smaller patches for<br>
> review. I am providing it as a reference to get the discussion started.<br>
><br>
> Please let me know what you think and bikeshed away :)<br>
><br>
> Thanks<br>
><br>
> Cheers,<br>
> Juergen<br>
><br>
><br>
><br>
><br>
><br>
><br>
</span>> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Davide<br>
<br>
"There are no solved problems; there are only problems that are more<br>
or less solved" -- Henri Poincare<br>
</font></span></blockquote></div><br></div></div>