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

Tue Jul 12 16:16:53 PDT 2022

jhuber6 added a comment.

In D129507#3646755 <https://reviews.llvm.org/D129507#3646755>, @MaskRay wrote:

> It's not an extension of ELF. It is a new format with content embedded in an ELF section (according to `while (Offset < Buffer->getBufferSize()) {` and `OffloadBinary::create`). 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.

FWIW I've pretty much deprecated three of those GPU/offloading tools and introduced two. We have a lot of these tools mostly because of legacy which I'm hoping will be removed in time. Generally the work I'm doing is noisy, but a net reduction in complexity. The features I'm adding here are not strictly necessary for functionality, but are meant to be convenient tools for users familiar with stuff like `cuobjdump` from Nvidia. I wouldn't think a new tool is necessary as the actual code required to support these features is relatively small and in-line with many other data formats embedded in an ELF.

In D129507#3646757 <https://reviews.llvm.org/D129507#3646757>, @MaskRay wrote:

> Note: `llvm-objcopy --dump-section .text=text a.out` rewrites `a.out` (the output is nearly indistinguishable, but the byte stream may be different). You need `llvm-objcopy --dump-section .text=text a.out /dev/null` to suppress the rewrite.
> This means `--dump-offloading` likely doesn't have good ergonomics in llvm-objcopy.

Noted, thanks.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129507