[PATCH] D53051: [llvm-tapi] initial commit, supports reading ELF

[Armando Montanez via Phabricator via llvm-commits]

amontanez added a comment.

While we’ve discussed what llvm-tapi intends to functionally do quite a bit, I might not have done a good job at outlining our goals for the project. This can be a bit of a stumbling block because our intended consequences of llvm-tapi aren’t the same as what Apple has done with Mach-O in the original TAPI. llvm-tapi will share much of the functionality of Apple’s open sourced TAPI, which is why the name was chosen as such. We didn’t want to upstream an ELF fork of it and completely ignore Apple’s TAPI. We took this as an opportunity to allow upstreaming both the Mach-O and ELF implementations. That is the rationale behind the naming decision.

The intended consequences for the ELF implementation, however, are going to be different than the direction Apple took with .dylib and .tbd. While we feel the textual representation of an ELF format is definitely useful, we don’t want things to depend on it the same way that Mach-O depends on .tbd files. The textual ELF stubs are intended to be a useful feature as-is, they don’t define a new format that anything (other than this tool) should really depend on. With that being said, there are still a few motivations for llvm-tapi to be a library. One is to allow better test coverage through unit tests, and another is to allow for other things to utilize the internal representation of API and ABI for analysis and tooling.

The short term functional goals of this project are to produce ELF object stubs with information sufficient for linking, and produce textual representations of these stubs for various user-defined purposes. This has been mentioned several times, so that is relatively clear at this point. The long term functional goals, however, haven’t been as clearly stated. We hope that in the future llvm-tapi will evolve to have helpful API/ABI related features in general. As a tangible example, Apple’s TAPI allows you to compare the API in a header file to the ABI implemented in the binary. Regardless of whether or not that particular feature appeals to your uses, llvm-tapi should be a good place for features in that vein. The initial RFC pointed to libabigail as another example of the sort of features that may be relevant to llvm-tapi. Reading and writing stubs is a necessary faculty before analysis tools can be integrated into the library, and the real features of llvm-tapi will extend beyond stubbing.


Repository:
  rL LLVM

https://reviews.llvm.org/D53051