[PATCH] D61767: [llvm-elfabi] Emit ELF header and string table section

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 23 11:09:37 PDT 2020


MaskRay added a comment.

In D61767#2331654 <https://reviews.llvm.org/D61767#2331654>, @phosek wrote:

> In D61767#2331624 <https://reviews.llvm.org/D61767#2331624>, @MaskRay wrote:
>
>> The purpose of this tool is still a bit unclear to me. Would you mind explaining a little? If you want to create a shared object writer, you can start from yaml2obj. Then there is natural question what generation features this tool can provide while yaml2obj cannot. If you want to write an interface shared object, sh_addr can be 0.
>
> We've had this discussion multiple times in the past so I'm not sure how much of that discussion we want to replay here. The somewhat short version is that `yaml2obj` is a testing tool intended to be used only within LLVM whereas `llvm-elfabi` is intended as a production tool shipped with your toolchain. The scope of these tools is also different: `llvm-elfabi` can generate a machine readable ABI description (we use YAML but that's an implementation detail, we're also considering other formats) for a given binary and then generate a stub from that description; `yaml2obj` only handles the latter part, but at the same time it also handles much broader range of use cases that are needed for testing and the YAML format it accepts has a lot of features we never want to expose to users. While I agree that there's some overlap between these tools, their use case is sufficiently different to warrant different tools in our opinion. There might be an opportunity for deduplicating some of the implementation, but that's also the case for `llvm-objcopy`/`llvm-strip`, and it's something we would like to handle separately in the future.

This rationale is fine. However, this effort is a resurrection of a very old patch. Many tools have documentation under `docs/CommandGuide` while llvm-elfabi doesn't.
I think others may have similar concerns as I did. If you want to address such concerns and make the scope of the tool clear, I hope you can put the link the last discussion in this patch or have something in the documentation.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61767/new/

https://reviews.llvm.org/D61767



More information about the llvm-commits mailing list