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

Hi @ll,

Over the past years I have been looking into how to reduce the size of the SDK
that ships with Xcode and how to improve build times for the overall OS inside
Apple. The result is a tool called TAPI, which is used at Apple for all things
related to text-based dynamic library files (.tbd).

What are text-based dynamic library files?
Text-based dynamic library files (TBDs) are a textual representation of the
information in a dynamic library / shared library that is required by the static
linker - basically a symbol list of the exported symbols.

Apple’s SDKs originally used Mach-O Dynamic Library Stubs. Mach-O Dynamic
Library Stubs are dynamic library files, but with all the text and data stripped
out. TBD files were introduced to replaced Mach-O Dynamic Library Stub files in
the SDK to further reduce its overall size.

Over time the TAPI tool has grown and is used now in a variety of ways.

Dynamic Library Stubbing:
As mentioned above, TAPI is used to read the content of dynamic library / shared
library and generates a textual representation that can be used by the static
linker. The current implementation reads MachO files, but it could be extended
to also provide the same functionality for other object file formats.

Framework / Dynamic Library Verification:
The symbols that are exported from a dynamic library should ideally match, or at
least contain, all the API that is specified in the associated header files.
TAPI performs this verification by parsing the header files with CLANG and
compare the findings to the exported symbols from the library.

InstallAPI:
InstallAPI is a new build phase that generates the TBD file from header files
only. This allows a dependency of the library to build concurrently even before
the library has been built itself. This can be used to increase parallelism in
the build or larger projects or operating systems.

Misc:
- display and operate on TBD files
- automatically generate API tests from header files
- libtapi, which is used by the linker (ld64) to parse the TBD files


The functionality of the tool is currently limited to Mach-O object files, but
that is not a technical limitation. In making the tool open source I hope others
will be able to take advantage of it too and extend its functionality to other
object file formats.


I initially developed the project as a CLANG project, but that was mostly for
practical reasons (out-of-tree development, separate repo, etc). For the curious
ones I pushed the repo to github (https://github.com/ributzka/tapi
<https://github.com/ributzka/tapi>).

I imagine, for example, that the reading/writing of TBD files is something that
would fit better into the LLVM sources, which makes it available to other
libraries and tools (e.g. LLVMObject, llvm-nm, lld, ...).

I created a small patch that integrates it with llvm-nm and LLVMObject. This
patch is not complete and I will split it up into smaller patches for review. I
am providing it as a reference to get the discussion started.

Please let me know what you think and bikeshed away :)

Thanks

Cheers,
Juergen




-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170907/4555e2da/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tapi-llvm-nm.patch.tar.bz2
Type: application/x-bzip2
Size: 16670 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170907/4555e2da/attachment.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170907/4555e2da/attachment-0001.html>

On Thu, Sep 7, 2017 at 5:01 PM, Juergen Ributzka via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi @ll,
>
> Over the past years I have been looking into how to reduce the size of the
> SDK that ships with Xcode and how to improve build times for the overall OS
> inside Apple. The result is a tool called TAPI, which is used at Apple for
> all things related to text-based dynamic library files (.tbd).
>
> What are text-based dynamic library files?
> Text-based dynamic library files (TBDs) are a textual representation of the
> information in a dynamic library / shared library that is required by the
> static linker - basically a symbol list of the exported symbols.
>
> Apple’s SDKs originally used Mach-O Dynamic Library Stubs. Mach-O Dynamic
> Library Stubs are dynamic library files, but with all the text and data
> stripped out. TBD files were introduced to replaced Mach-O Dynamic Library
> Stub files in the SDK to further reduce its overall size.
>
> Over time the TAPI tool has grown and is used now in a variety of ways.
>
> Dynamic Library Stubbing:
> As mentioned above, TAPI is used to read the content of dynamic library /
> shared library and generates a textual representation that can be used by
> the static linker. The current implementation reads MachO files, but it
> could be extended to also provide the same functionality for other object
> file formats.
>
> Framework / Dynamic Library Verification:
> The symbols that are exported from a dynamic library should ideally match,
> or at least contain, all the API that is specified in the associated header
> files. TAPI performs this verification by parsing the header files with
> CLANG and compare the findings to the exported symbols from the library.
>
> InstallAPI:
> InstallAPI is a new build phase that generates the TBD file from header
> files only. This allows a dependency of the library to build concurrently
> even before the library has been built itself. This can be used to increase
> parallelism in the build or larger projects or operating systems.
>
> Misc:
> - display and operate on TBD files
> - automatically generate API tests from header files
> - libtapi, which is used by the linker (ld64) to parse the TBD files
>
I'm interested in whether you plan to have this integrated in lld as well.
As far as I understand, this is going to be the de-facto way of
shipping for Mach-O binaries (at least, the ones released by Apple).
Please correct me if I'm wrong.
I tried to self-host lld on El Capitan and it fails because lld
doesn't really know about TBD files.
This, unfortunately, makes the linker not really usable for modern Mac
OS releases.
>
> The functionality of the tool is currently limited to Mach-O object files,
> but that is not a technical limitation. In making the tool open source I
> hope others will be able to take advantage of it too and extend its
> functionality to other object file formats.
>
>
> I initially developed the project as a CLANG project, but that was mostly
> for practical reasons (out-of-tree development, separate repo, etc). For
the
> curious ones I pushed the repo to github
(https://github.com/ributzka/tapi).
>
> I imagine, for example, that the reading/writing of TBD files is something
> that would fit better into the LLVM sources, which makes it available to
> other libraries and tools (e.g. LLVMObject, llvm-nm, lld, ...).
>
> I created a small patch that integrates it with llvm-nm and LLVMObject.
This
> patch is not complete and I will split it up into smaller patches for
> review. I am providing it as a reference to get the discussion started.
>
> Please let me know what you think and bikeshed away :)
>
> Thanks
>
> Cheers,
> Juergen
>
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare

> InstallAPI:
> InstallAPI is a new build phase that generates the TBD file from header
> files only. This allows a dependency of the library to build concurrently
> even before the library has been built itself. This can be used to
> increase parallelism in the build or larger projects or operating systems.
My experience is that headers don't necessarily form the best source of
truth about the API exported from a library.  If you follow the Windows
model of marking exported APIs explicitly (declspec(dllexport) or something)
then okay, but that's a Windows extension and not common in other systems.
Linker scripts seem to be a more popular method; does the tool read linker
scripts to form the content of a TBD file?
Otherwise I'm not seeing a generic improvement in build parallelism.
--paulr

On Thu, Sep 7, 2017 at 6:52 PM, Davide Italiano <davide at freebsd.org>
wrote:
> On Thu, Sep 7, 2017 at 5:01 PM, Juergen Ributzka via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Hi @ll,
> >
> > Over the past years I have been looking into how to reduce the size of
> the
> > SDK that ships with Xcode and how to improve build times for the
overall
> OS
> > inside Apple. The result is a tool called TAPI, which is used at Apple
> for
> > all things related to text-based dynamic library files (.tbd).
> >
> > What are text-based dynamic library files?
> > Text-based dynamic library files (TBDs) are a textual representation
of
> the
> > information in a dynamic library / shared library that is required by
the
> > static linker - basically a symbol list of the exported symbols.
> >
> > Apple’s SDKs originally used Mach-O Dynamic Library Stubs. Mach-O
Dynamic
> > Library Stubs are dynamic library files, but with all the text and
data
> > stripped out. TBD files were introduced to replaced Mach-O Dynamic
> Library
> > Stub files in the SDK to further reduce its overall size.
> >
> > Over time the TAPI tool has grown and is used now in a variety of
ways.
> >
> > Dynamic Library Stubbing:
> > As mentioned above, TAPI is used to read the content of dynamic
library /
> > shared library and generates a textual representation that can be used
by
> > the static linker. The current implementation reads MachO files, but
it
> > could be extended to also provide the same functionality for other
object
> > file formats.
> >
> > Framework / Dynamic Library Verification:
> > The symbols that are exported from a dynamic library should ideally
> match,
> > or at least contain, all the API that is specified in the associated
> header
> > files. TAPI performs this verification by parsing the header files
with
> > CLANG and compare the findings to the exported symbols from the
library.
> >
> > InstallAPI:
> > InstallAPI is a new build phase that generates the TBD file from
header
> > files only. This allows a dependency of the library to build
concurrently
> > even before the library has been built itself. This can be used to
> increase
> > parallelism in the build or larger projects or operating systems.
> >
> > Misc:
> > - display and operate on TBD files
> > - automatically generate API tests from header files
> > - libtapi, which is used by the linker (ld64) to parse the TBD files
> >
>
> I'm interested in whether you plan to have this integrated in lld as
well.
> As far as I understand, this is going to be the de-facto way of
> shipping for Mach-O binaries (at least, the ones released by Apple).
> Please correct me if I'm wrong.
>
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.

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.

> I tried to self-host lld on El Capitan and it fails because lld
> doesn't really know about TBD files.
> This, unfortunately, makes the linker not really usable for modern Mac
> OS releases.
>
> >
> > The functionality of the tool is currently limited to Mach-O object
> files,
> > but that is not a technical limitation. In making the tool open source
I
> > hope others will be able to take advantage of it too and extend its
> > functionality to other object file formats.
> >
> >
> > I initially developed the project as a CLANG project, but that was
mostly
> > for practical reasons (out-of-tree development, separate repo, etc).
For
> the
> > curious ones I pushed the repo to github (https://github.com/ributzka/
> tapi).
> >
> > I imagine, for example, that the reading/writing of TBD files is
> something
> > that would fit better into the LLVM sources, which makes it available
to
> > other libraries and tools (e.g. LLVMObject, llvm-nm, lld, ...).
> >
> > I created a small patch that integrates it with llvm-nm and
LLVMObject.
> This
> > patch is not complete and I will split it up into smaller patches for
> > review. I am providing it as a reference to get the discussion
started.
> >
> > Please let me know what you think and bikeshed away :)
> >
> > Thanks
> >
> > Cheers,
> > Juergen
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> --
> Davide
>
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170908/ffdd50a3/attachment-0001.html>

Hi Paul,

My experience has shown the same when it comes to header files and I am not
claiming this is going to work out of the box for all library projects. It
usually requires some cleanup first and that is why the tool comes with a
verification mode to make sure the headers are the truth. Also keep in mind
that you don't have to parse all the headers, but only the small set that
get installed as part of the library API.

The tool does not read the linker script / export file, because they are
not necessarily the truth either and may have wildcards. In my view they
are just one way of managing exported symbols. Another way, which I
personally prefer, is to build with visibility hidden and annotate only the
API with visibility default. That makes the headers the single source of
what is API.

Cheers,
Juergen



On Fri, Sep 8, 2017 at 9:29 AM, Robinson, Paul <paul.robinson at sony.com>
wrote:
> > InstallAPI:
> > InstallAPI is a new build phase that generates the TBD file from
header
> > files only. This allows a dependency of the library to build
concurrently
> > even before the library has been built itself. This can be used to
> > increase parallelism in the build or larger projects or operating
> systems.
>
> My experience is that headers don't necessarily form the best source of
> truth about the API exported from a library.  If you follow the Windows
> model of marking exported APIs explicitly (declspec(dllexport) or
> something)
> then okay, but that's a Windows extension and not common in other
systems.
> Linker scripts seem to be a more popular method; does the tool read linker
> scripts to form the content of a TBD file?
> Otherwise I'm not seeing a generic improvement in build parallelism.
> --paulr
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170908/3d6eae57/attachment.html>

Hi Juergen,

At a minimum I think adding the support to libobject, etc so the various
llvm tools can read or even write files from/for OSX should be fairly
non-controversial so how about go ahead and do that first (I'll happily
review if you'd like) and then we can go from there to do anything else
with TAPI and llvm?

Sound good?

-eric

On Thu, Sep 7, 2017 at 5:01 PM Juergen Ributzka via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Hi @ll,
>
> Over the past years I have been looking into how to reduce the size of the
> SDK that ships with Xcode and how to improve build times for the overall OS
> inside Apple. The result is a tool called TAPI, which is used at Apple for
> all things related to text-based dynamic library files (.tbd).
>
> *What are text-based dynamic library files?*
> Text-based dynamic library files (TBDs) are a textual representation of
> the information in a dynamic library / shared library that is required by
> the static linker - basically a symbol list of the exported symbols.
>
> Apple’s SDKs originally used Mach-O Dynamic Library Stubs. Mach-O Dynamic
> Library Stubs are dynamic library files, but with all the text and data
> stripped out. TBD files were introduced to replaced Mach-O Dynamic Library
> Stub files in the SDK to further reduce its overall size.
>
> Over time the TAPI tool has grown and is used now in a variety of ways.
>
> *Dynamic Library Stubbing:*
> As mentioned above, TAPI is used to read the content of dynamic library /
> shared library and generates a textual representation that can be used by
> the static linker. The current implementation reads MachO files, but it
> could be extended to also provide the same functionality for other object
> file formats.
>
> *Framework / Dynamic Library Verification:*
> The symbols that are exported from a dynamic library should ideally match,
> or at least contain, all the API that is specified in the associated header
> files. TAPI performs this verification by parsing the header files with
> CLANG and compare the findings to the exported symbols from the library.
>
> *InstallAPI:*
> InstallAPI is a new build phase that generates the TBD file from header
> files only. This allows a dependency of the library to build concurrently
> even before the library has been built itself. This can be used to increase
> parallelism in the build or larger projects or operating systems.
>
> *Misc:*
> - display and operate on TBD files
> - automatically generate API tests from header files
> - libtapi, which is used by the linker (ld64) to parse the TBD files
>
>
> The functionality of the tool is currently limited to Mach-O object files,
> but that is not a technical limitation. In making the tool open source I
> hope others will be able to take advantage of it too and extend its
> functionality to other object file formats.
>
>
> I initially developed the project as a CLANG project, but that was mostly
> for practical reasons (out-of-tree development, separate repo, etc). For
> the curious ones I pushed the repo to github (
> https://github.com/ributzka/tapi).
>
> I imagine, for example, that the reading/writing of TBD files is something
> that would fit better into the LLVM sources, which makes it available to
> other libraries and tools (e.g. LLVMObject, llvm-nm, lld, ...).
>
> I created a small patch that integrates it with llvm-nm and LLVMObject.
> This patch is not complete and I will split it up into smaller patches for
> review. I am providing it as a reference to get the discussion started.
>
> Please let me know what you think and bikeshed away :)
>
> Thanks
>
> Cheers,
> Juergen
>
>
>
>
> _______________________________________________
> 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/20171025/1981f527/attachment.html>

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?

If anyone wants to do something similar for another platform (that is to
say, ELF; COFF already has import libraries), I'd suggest that the sensible
way to do so would be to generate actual shared object files which contain
only the appropriate interface definitions.

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.


On Thu, Sep 7, 2017 at 8:01 PM, Juergen Ributzka via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Hi @ll,
>
> Over the past years I have been looking into how to reduce the size of the
> SDK that ships with Xcode and how to improve build times for the overall OS
> inside Apple. The result is a tool called TAPI, which is used at Apple for
> all things related to text-based dynamic library files (.tbd).
>
> *What are text-based dynamic library files?*
> Text-based dynamic library files (TBDs) are a textual representation of
> the information in a dynamic library / shared library that is required by
> the static linker - basically a symbol list of the exported symbols.
>
> Apple’s SDKs originally used Mach-O Dynamic Library Stubs. Mach-O Dynamic
> Library Stubs are dynamic library files, but with all the text and data
> stripped out. TBD files were introduced to replaced Mach-O Dynamic Library
> Stub files in the SDK to further reduce its overall size.
>
> Over time the TAPI tool has grown and is used now in a variety of ways.
>
> *Dynamic Library Stubbing:*
> As mentioned above, TAPI is used to read the content of dynamic library /
> shared library and generates a textual representation that can be used by
> the static linker. The current implementation reads MachO files, but it
> could be extended to also provide the same functionality for other object
> file formats.
>
> *Framework / Dynamic Library Verification:*
> The symbols that are exported from a dynamic library should ideally match,
> or at least contain, all the API that is specified in the associated header
> files. TAPI performs this verification by parsing the header files with
> CLANG and compare the findings to the exported symbols from the library.
>
> *InstallAPI:*
> InstallAPI is a new build phase that generates the TBD file from header
> files only. This allows a dependency of the library to build concurrently
> even before the library has been built itself. This can be used to increase
> parallelism in the build or larger projects or operating systems.
>
> *Misc:*
> - display and operate on TBD files
> - automatically generate API tests from header files
> - libtapi, which is used by the linker (ld64) to parse the TBD files
>
>
> The functionality of the tool is currently limited to Mach-O object files,
> but that is not a technical limitation. In making the tool open source I
> hope others will be able to take advantage of it too and extend its
> functionality to other object file formats.
>
>
> I initially developed the project as a CLANG project, but that was mostly
> for practical reasons (out-of-tree development, separate repo, etc). For
> the curious ones I pushed the repo to github (
> https://github.com/ributzka/tapi).
>
> I imagine, for example, that the reading/writing of TBD files is something
> that would fit better into the LLVM sources, which makes it available to
> other libraries and tools (e.g. LLVMObject, llvm-nm, lld, ...).
>
> I created a small patch that integrates it with llvm-nm and LLVMObject.
> This patch is not complete and I will split it up into smaller patches for
> review. I am providing it as a reference to get the discussion started.
>
> Please let me know what you think and bikeshed away :)
>
> Thanks
>
> Cheers,
> Juergen
>
>
>
>
>
>
> _______________________________________________
> 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/20180409/c553d2a2/attachment.html>

> 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

Sound great :)

On Wed, Oct 25, 2017 at 4:28 PM, Eric Christopher <echristo at gmail.com>
wrote:
> Hi Juergen,
>
> At a minimum I think adding the support to libobject, etc so the various
> llvm tools can read or even write files from/for OSX should be fairly
> non-controversial so how about go ahead and do that first (I'll happily
> review if you'd like) and then we can go from there to do anything else
> with TAPI and llvm?
>
> Sound good?
>
> -eric
>
> On Thu, Sep 7, 2017 at 5:01 PM Juergen Ributzka via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Hi @ll,
>>
>> Over the past years I have been looking into how to reduce the size of
>> the SDK that ships with Xcode and how to improve build times for the
>> overall OS inside Apple. The result is a tool called TAPI, which is
used at
>> Apple for all things related to text-based dynamic library files
(.tbd).
>>
>> *What are text-based dynamic library files?*
>> Text-based dynamic library files (TBDs) are a textual representation of
>> the information in a dynamic library / shared library that is required
by
>> the static linker - basically a symbol list of the exported symbols.
>>
>> Apple’s SDKs originally used Mach-O Dynamic Library Stubs. Mach-O
Dynamic
>> Library Stubs are dynamic library files, but with all the text and data
>> stripped out. TBD files were introduced to replaced Mach-O Dynamic
Library
>> Stub files in the SDK to further reduce its overall size.
>>
>> Over time the TAPI tool has grown and is used now in a variety of ways.
>>
>> *Dynamic Library Stubbing:*
>> As mentioned above, TAPI is used to read the content of dynamic library
/
>> shared library and generates a textual representation that can be used
by
>> the static linker. The current implementation reads MachO files, but it
>> could be extended to also provide the same functionality for other
object
>> file formats.
>>
>> *Framework / Dynamic Library Verification:*
>> The symbols that are exported from a dynamic library should ideally
>> match, or at least contain, all the API that is specified in the
associated
>> header files. TAPI performs this verification by parsing the header
files
>> with CLANG and compare the findings to the exported symbols from the
>> library.
>>
>> *InstallAPI:*
>> InstallAPI is a new build phase that generates the TBD file from header
>> files only. This allows a dependency of the library to build
concurrently
>> even before the library has been built itself. This can be used to
increase
>> parallelism in the build or larger projects or operating systems.
>>
>> *Misc:*
>> - display and operate on TBD files
>> - automatically generate API tests from header files
>> - libtapi, which is used by the linker (ld64) to parse the TBD files
>>
>>
>> The functionality of the tool is currently limited to Mach-O object
>> files, but that is not a technical limitation. In making the tool open
>> source I hope others will be able to take advantage of it too and
extend
>> its functionality to other object file formats.
>>
>>
>> I initially developed the project as a CLANG project, but that was
mostly
>> for practical reasons (out-of-tree development, separate repo, etc).
For
>> the curious ones I pushed the repo to github (
>> https://github.com/ributzka/tapi).
>>
>> I imagine, for example, that the reading/writing of TBD files is
>> something that would fit better into the LLVM sources, which makes it
>> available to other libraries and tools (e.g. LLVMObject, llvm-nm, lld,
...).
>>
>> I created a small patch that integrates it with llvm-nm and LLVMObject.
>> This patch is not complete and I will split it up into smaller patches
for
>> review. I am providing it as a reference to get the discussion started.
>>
>> Please let me know what you think and bikeshed away :)
>>
>> Thanks
>>
>> Cheers,
>> Juergen
>>
>>
>>
>>
>> _______________________________________________
>> 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/20180425/b73183cb/attachment.html>