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

[Armando Montanez via Phabricator via llvm-commits]

amontanez added a comment.

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

> I'd like to start with a high level comment too. I wonder if your final vision includes adding native support of ELF TAPI to lld. As I expressed in the mailing list threads for the proposal, honestly, I'm not still convinced that TAPI for ELF is a good idea, considering the amount of overlap that the regular ELF and ELF TAPI can do and the cost of adding a completely new format. A lot of things you can do with ELF TAPI can also be done with the regular ELF format, and looks like other benefits you would get with ELF TAPI be achieved with more lightweight approach. I think I cannot support adding ELF TAPI to lld if you have a plan to do so. To convince me, can you please give me examples that ELF TAPI is absolutely needed/useful?


To answer your first question directly: this tool doesn't demand that lld supports linking against textual ELF stubs. The binary ELF stubs emitted from this tool will behave just like any other ELF stub used for linking, they won't present anything new that would require any changes to lld. As a broader statement, this project doesn't necessitate any changes to lld.

With that said, there's a slightly more indirect answer. Linking against the textual format was brought up because we felt it could be a useful feature to eventually consider. This is not a core aspect of llvm-tapi, it was just brought up tangentially as a potential direction. It's clear there's pushback against that, so I've taken your feedback and will begin a separate discussion if/when it resurfaces as part of a roadmap. llvm-tapi is still very useful without lld directly supporting linking against textual stubs.

They key focus right now is that we have a tool that can emit a relatively lightweight textual representation of the exposed symbols in a DSO (for tracking and otherwise controlling the exposed binary interface), and additionally emit a linkable binary stub.

- The binary format is not new; it's just an ELF file with everything the linker should need for linking dynamic shared objects.
- If you don't think using YAML IO is the right approach for the textual format, we're open to suggestions.
- While the input will typically be an ELF dynamic shared object, it's helpful to be able to generate the binary stub from the textual representation as well. This is because of several reasons:
  - When only having an ELF stub suffices, distributing both the textual and binary stub would be redundant.
  - Distributing only the binary stub wouldn't directly provide as much information to users.
  - Checking a binary file into a repository doesn't show what has changed in the way a textual format would.
  - From what I've seen in my brief testing, textual stubs are around 20% smaller when compressed than their binary counterparts (also compressed).
- Further features for insight/analysis/comparison/etc. can stem from this. Producing binary/textual stubs, though useful in and of itself, is a feature that gives this tool necessary read/write facilities that are required before introducing other features.

Hopefully this clarifies things a bit.


Repository:
  rL LLVM

https://reviews.llvm.org/D53051