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
