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

[Petr Hosek via Phabricator via llvm-commits]

phosek added a comment.

In https://reviews.llvm.org/D53051#1277504, @ruiu wrote:

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


To take a step back, here are the requirements that we have:

1. A tool that can read an ELF file and write an ELF stub
2. A tool that can read an ELF file and write a human & machine readable textual representation
3. A tool that can read the human & machine readable textual representation and write an ELF stub

In addition, we have some non-functional requirements:

1. We want to avoid any additional post-processing
2. Ideally this would be a single tool to simplify the use and distribution

What we're working on is a minimal implementation that satisfies these requirements. What you seem to be suggesting is that instead of satisfying all of the functional requirements with a single tool, we'll split them between two different tools: `llvm-tapi`for (1) and (3), and `llvm-nm` for (2). What I don't understand is why do you think it's better to use two different tools rather one, especially since these these tools would need to agree on the textual representation. Can you please elaborate on that?


Repository:
  rL LLVM

https://reviews.llvm.org/D53051