[llvm] Add --dump-offload-bundle option to llvm-objcopy (PR #143347)

[James Henderson via llvm-commits]

jh7370 wrote:

> I see yoour point. Though I still feel that llvm-objcopy is the right tool, because what this option is trying to do is a raw copy (or extraction) of part of a section in an object file. Most of the functionality of llvm-objcopy seems to be based on copying whole sections; but also some fine grain control at the symbol level too.

Actually, llvm-objcopy is predominantly about copying whole files, manipulating things along the way. The process operates on sections (among other things), because it's easier to manipulate that way, but that's an implementation detail. Note the tool name is short for "object copy". This copying is pretty fundamental to the behaviour.

> This option is similar in that it is copying data from a section, though in this case a very specific section - the Clang fatbin bundle offload section. The problem really is that the URI syntax contains/encapsulates all of the information needed to do the copy/extract, so we don't need an explicit input file. I could remove the code to disable the need to specify an input file, then users would need to specify the URI for the option --dump-offload-bundle as well as the input file - so something like this "llvm-objcopy --dump-offload-bundle=file:://test.exe#offset=4096&size=1024 test.exe". This is doable, but not too pretty.

This would fit better into llvm-objcopy, since the object copying is still happening. You may want to consider allowing a simplified version of the syntax, as well as the full syntax. Something like `--dump-offload-bundle=offset=4096&size=1024` (while also still accepting the full format, in which case I'd make it a requirement that the `file:://test.exe` matches the input file name). You could then internally rebuild the URI, if needed.

https://github.com/llvm/llvm-project/pull/143347