How to do target-specific linking for OpenMP

Dear all,

we are developing a Clang/LLVM 9 Toolchain + Backend together with an OpenMP offloading RTL for our own hardware accelerator. Since our offload entries contain only simple, self-contained binary code which does not have to be linked against any libraries, we were able to get everything running for a single source file with offload entries by simply copying the created file.o to a.out-openmp-<architecture>-elf, which is then embedded in the host binary using the linker script. At runtime, we can then read the offload entries from the unmodified .o file effectively.

However, if we want to combine several such .o files into a single a.out, we have to combine the contents of the .omp_offloading related sections in the .o files to a single one doing some actual "linking", or better "relocations".

I tried to employ the system linker ld to this end, e.g using several versions of simple linker scripts, but the problem is that ld refuses to do the work with the error "Relocations in generic ELF (EM: 248)". As far as I understand, the reason is that it does not understand the binary format.

My question is: What would be the easiest way to do the necessary combining of our .o files? Is it possible to do it via llvm lld in a simple way, or by using a certain way of linker scripts for ld? My problem is that I do not precisely understand the interplay of the way we create our .o files using our derived form of MCELFObjectTargetWriter and the necessary linking process.

Any help would be greatly appreciated.


Kai Plociennik

Hi Kai,

any reason you don't want to do the same as clang and use the "clang offload bundler"?

I'm hoping to move this logic into a linker plugin but so far we haven't started.

~ Johannes

% cat a.s
call foo
% cc -c a.s
% ld.bfd --accept-unknown-input-arch a.o
ld.bfd: a.o: Relocations in generic ELF (EM: 84)
ld.bfd: a.o: error adding symbols: file in wrong format

Your object files have relocations. If ld.bfd does not known the
machine, it cannot correctly apply relocations, hence the error.
If the files use relocations, it should have a machine which is
recognized by your toolchain. If there is no relocation,
ld.bfd --accept-unknown-input-arch can concatenate input sections.