These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
Utilize the new extensions to the LLVM Offloading API to extend to
llvm-objdump to handle dumping fatbin offload bundles generated by HIP.
This extension to llvm-objdump adds the option --offload-fatbin.
Specifying this option will take the input object/executable and extract
all offload fatbin bundle entries into distinct code object files with
names reflecting the source file name combined with the Bundle Entry ID.
Users can also use the --arch-name option to filter offload fatbin
bundle entries by their target triple.
---------
Co-authored-by: dsalinas <dsalinas@MKM-L1-DSALINAS.amd.com>
Utilize the new extensions to the LLVM Offloading API to extend to
llvm-objdump to handle dumping fatbin offload bundles generated by HIP.
This extension to llvm-objdump adds the option --offload-fatbin.
Specifying this option will take the input object/executable and extract
all offload fatbin bundle entries into distinct code object files with
names reflecting the source file name combined with the Bundle Entry ID.
Users can also use the --arch-name option to filter offload fatbin
bundle entries by their target triple.
---------
Co-authored-by: dsalinas <dsalinas@MKM-L1-DSALINAS.amd.com>
Utilize the new extensions to the LLVM Offloading API to extend to
llvm-objdump to handle dumping fatbin offload bundles generated by HIP.
This extension to llvm-objdump adds the option --offload-fatbin.
Specifying this option will take the input object/executable and extract
all offload fatbin bundle entries into distinct code object files with
names reflecting the source file name combined with the Bundle Entry ID.
Users can also use the --arch-name option to filter offload fatbin
bundle entries by their target triple.
---------
Co-authored-by: dsalinas <dsalinas@MKM-L1-DSALINAS.amd.com>
This patch adds initial support for extracting offloading binaries from
`COFF` objects. This is a first step to allow building offloading files
on Windows targets with the new driver.
Depends on D136796
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D136855
A previous patch introduced a common function used to extract offloading
binaries from an image. Therefore we no longer need to duplicate the
functionality in the `llvm-objdump` implementation. Functionally, this
removes the old warning behaviour when given malformed input. This has
been changed to a hard error, which is effectively the same.
This required a slight tweak in the linker wrapper to filter out the
user passing shared objects directly.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D136796
Summary:
The `.llvm.offloading` section should always be aligned by `8`. However,
we may want to show the offloading data stored in a static library. In
this case, even though the section's alignment is correct, the offset
inside the archive will result in the memory buffer being misaligned. TO
combat this we simply check if the buffer does not have the proper
alignment and copies it to a new buffer if not. This copy should have
the proper alignment.
In order to be more in-line with ELF semantics, a previous patch added
support for a new ELF section type to indicate if a section contains
offloading data. This allows us to now check using this rather than
checking the section name directly. This patch updates the logic to
check the type now instead.
I chose to make this emit a warning if the input is not an ELF-object
file. I could have made the logic fall-back to the section name, but
this offloading in LLVM is currently not supported on any other targets
so it's probably best to emit a warning until we improve support.
Depends on D129052
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D129053
In Clang/LLVM we are moving towards a new binary format to store many
embedded object files to create a fatbinary. This patch adds support for
dumping these embedded images in the `llvm-objdump` tool. This will
allow users to query information about what is stored inside the binary.
This has very similar functionality to the `cuobjdump` tool for thoe familiar
with the Nvidia utilities. The proposed use is as follows:
```
$ clang input.c -fopenmp --offload-arch=sm_70 --offload-arch=sm_52 -c
$ llvm-objdump -O input.o
input.o: file format elf64-x86-64
OFFLOADIND IMAGE [0]:
kind cubin
arch sm_52
triple nvptx64-nvidia-cuda
producer openmp
OFFLOADIND IMAGE [1]:
kind cubin
arch sm_70
triple nvptx64-nvidia-cuda
producer openmp
```
This will be expanded further once we start embedding more information
into these offloading images. Right now we are planning on adding
flags and entries for debug level, optimization, LTO usage, target
features, among others.
This patch only supports printing these sections, later we will want to
support dumping files the user may be interested in via another flag. I
am unsure if this should go here in `llvm-objdump` or `llvm-objcopy`.
Reviewed By: MaskRay, tra, jhenderson, JonChesterfield
Differential Revision: https://reviews.llvm.org/D126904
