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

[Petr Hosek via Phabricator via llvm-commits]

phosek added a comment.

To clarify, we're not trying to build an exact copy of Apple's TAPI for ELF. We believe there are aspects of the implementation that can be reused across formats hence using the same name, but our approach is slightly different and more specific to ELF.

What we're working towards is a tool that can produce an ELF stub (aka interface library, ABI library) from a given ELF file. I believe we're in agreement here with what @ruiu and @compnerd are suggesting. TAPI file in this case is an intermediate output. Having the intermediate, human readable, textual output is really valuable for our use cases. @amontanez has already covered many of those use cases in his response. Most importantly, that output can be checked into a repository and then compared against newer changes. Many projects already do this today with ad-hoc solutions, e.g. libc++ and its abilist files <https://github.com/llvm-mirror/libcxx/blob/master/lib/abi/6.0/x86_64-unknown-linux-gnu.abilist>.

We don't think `llvm-nm` is appropriate for that use case for several reasons. First of all, while the output of `llvm-nm` can be used for the ABI/API verification, it contains extra information that's irrelevant and needs to be filtered out. In fact, we already have a custom ad-hoc script in Fuchsia that's used for producing ELF stubs and uses `llvm-nm` under the hood, and the filtering is one of the pain points. Second, having a single tool for producing both the stub and the intermediate output is more elegant and more efficient, e.g. compare `llvm-tapi -emit-tbe foo.tapi -o foo.abi.so foo.so` (exact CLI is TBD) vs `llvm-tapi -o foo.abi.so foo.so && llvm-nm -format yaml | filter_output.py > foo.tapi`. Finally, `llvm-nm` implementation is currently writing its output by directly writing to stdout, to support machine readable output, it require substantial refactoring/rewrite to store all the information in intermediate structure which could be serialized to chosen format or printed to stdout just like today.

We'd also like to be able to read the textual representation and generate the ELF stub directly out of it so we need a library for reading/writing the intermediate format. I'd much rather have more purpose-built tool than trying to bolt on that functionality to an existing tool that wasn't designed for that purpose.

I also want to emphasize that this change is not a complete tool, it's the first in a series of changes. The reason we've decided to split the implementation into multiple patches is because we think it'll be easier to review. @amontanez is already working on the second change that allows writing the ELF stubs in https://reviews.llvm.org/D53682 (although the change is not yet ready for review).


Repository:
  rL LLVM

https://reviews.llvm.org/D53051