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

[James Henderson via llvm-commits]

jh7370 wrote:

> What the --dump-offload-bundle option is trying to do is to extract a specific bundle entry (or entries) in the Clang Offload Bundle section of the object file (https://clang.llvm.org/docs/ClangOffloadBundler.html#bundled-binary-file-layout). And to allow users to specify the specific bundle entry we are using a URI syntax for the argument to the --dump-offload-bundle option. This is spec on the URI syntax:
> 
> ```
> code_object_uri ::== file_uri | memory_uri
> file_uri        ::== file:// extract_file [ range_specifier ]
> memory_uri      ::== memory:// process_id range_specifier
> range_specifier ::== [ # | ? ] offset= number & size= number
> extract_file    ::== URI_ENCODED_OS_FILE_PATH
> process_id      ::== DECIMAL_NUMBER
> number          ::== HEX_NUMBER | DECIMAL_NUMBER | OCTAL_NUMBER
> ``` 
> I'm hesitant to add this to the llvm-objcopy documentation as it is probably too much detail to add?  It is the same URI syntax that llvm-readobj --offloading generates.

Presumably the user can't know the `number` parameter (and potentially not the `process_id` either) without using llvm-readobj to dump it? If that's the case, I agree documenting the full syntax here probably doesn't make sense, but I do think you need to document how to obtain it.

> Anyway, the issue is that the URI syntax already contains the source file name from where to copy/extract, so a source file name is not really needed. I did spend some time trying to see which llvm-* tool would better support this functionality. But llvm-objcopy is what I ended up choosing, as it seemed to make the most sense for what we're trying to accomplish; copying/extract specific parts of an Object file's offload bundle section..

Thanks, I see what you're saying. However, I think it's clear from what you've done that this shouldn't be an llvm-objcopy feature, as you're essentially introducing a second mode to the tool that is completely unrelated to the current mode and where there's no mixing of the two. The core of llvm-objcopy and its sibling tools like llvm-strip, is to call `executeObjcopy`, which when the new option you're adding is used, is never executed. That suggests to me that this functionality belongs in a different, potentially completely new, tool.

>  Maybe I have an old clang-format file?

That sounds plausible.

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