[PATCH] D129507: [llvm-objcopy] Add option to dump embedded offloading images

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 12 15:53:07 PDT 2022


MaskRay added a subscriber: avl.
MaskRay added a comment.

In D129507#3643307 <https://reviews.llvm.org/D129507#3643307>, @tra wrote:

> In D129507#3643246 <https://reviews.llvm.org/D129507#3643246>, @MaskRay wrote:
>
>> The feature doesn't fit into llvm-objcopy's purpose. llvm-objcopy is a binary manipulation tool which only understands ELF. `--dump-offloading` seems to parse the content using knowledge of the underlying format.
>
> Which tool would be appropriate for something like this? Do you suggest that we need a new tool?
>
> The "only understands ELF" part may be open to interpretation. If one were to implement an extension to ELF format, would objcopy be the right place to support it? While `objdump` does have knowledge of the underlying formats, it does not deal with extraction of such data, but rather interprets it for human consumption.
> This use case is somewhere in between -- it involves binary data manipulation, which is what objcopy does, but it does require some knowledge of the underlying format.

For example, @avl wanted to create a DWARF utility and I vaguely recall there was a discussion whether it applied to llvm-objcopy.
The answer is no as llvm-objcopy shouldn't know how to parse llvm-objcopy.

> IMO, the offloading packing format is closer to being an extension of ELF, than being yet another ISA to disassemble (i.e. it's simple, generic and unlikely to change much) and objcopy seems like a decent fit. Offloading data manipulation may eventually be extended to insert new offload binaries, too, which would also fit objcopy functionality nicely.

It's not an extension of ELF. It is a new format with content embedded in an ELF section. I don't really keep up-to-date with the already-plethora of GPU/offloading tools so I do not have an idea out of my head. If adding a new tool seems to be overkill, GPU/offloading folks may need to re-think how to reorganize the tools.
The question isn't raised for the first time why we have so many llvm-*/clang-* tools doing GPU/offloading stuff now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129507



More information about the llvm-commits mailing list