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

[Rui Ueyama via Phabricator via llvm-commits]

ruiu added a comment.

> 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.

What I had in mind when I read Saleem's reply is to define a completely new text file format for `llvm-nm -format llvm` or `llvm-nm -format yaml`, so it doesn't matter what we are currently printing out from nm. You can define a new file format as you want, add anything you want to the file format, and exclude anything that you don't want from the file format. That's the point of adding a new command line flag to an exiting command -- you don't need to care about backward compatibility at all.

I do not also see any problem of adding a new command to convert between a textual ELF stub file and a binary ELF stub file. That should not be that different from adding a new command line flag to an existing command. We may call the new command `llvm-tapi`. I clearly see the benefit of having a command that is capable of converting an ELF stub file to its textual representation and vice versa.

> 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.

But if you want to add a native support of the new text representation to beyond a single command, I do not see a reason to do so. Is there any reason you can't use the command to convert a text stub to an actual ELF file before doing the stuff what you want to do with your tool? I'm very worried that we'd end up in a situation that we need to add a native support of the new ELF TAPI format to other tools because one tool support it natively. I really want to avoid that situation, and it seems to me that it is better to not do that from the beginning.


Repository:
  rL LLVM

https://reviews.llvm.org/D53051