<div dir="ltr">I understand that, but if I put the "target.o" for example in a static library libtarget.a, at link time the clang driver does not call "clang-offload-bundler" on the static library and I get undefined references because it can't find the definitions that are inside the library.<div>So I just wanted to bring up this problem, because either I am doing something wrong or it's a limitation of the driver/bundler.</div><div><br></div><div>As I said, I wanted to bring this up to make sure we know what to do when we start implementing the offload support on Flang.</div><div><br></div><div>Thanks Jonas!</div><div>Simone<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 11, 2018 at 1:20 PM, Jonas Hahnfeld <span dir="ltr"><<a href="mailto:hahnjo@hahnjo.de" target="_blank">hahnjo@hahnjo.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is implemented so that no changes to the build system are necessary. Have a look at the class ObjectFileHandler (<a href="https://github.com/llvm-mirror/clang/blob/f0382ad/tools/clang-offload-bundler/ClangOffloadBundler.cpp#L370" rel="noreferrer" target="_blank">https://github.com/llvm-mirro<wbr>r/clang/blob/f0382ad/tools/<wbr>clang-offload-bundler/ClangOff<wbr>loadBundler.cpp#L370</a>).<br>
<br>
$ clang -fopenmp -fopenmp-targets=x86_64-unknow<wbr>n-linux-gnu -c target.c<br>
$ objdump -h target.o<br>
<br>
target.o:     file format elf64-x86-64<br>
<br>
Sections:<br>
Idx Name          Size      VMA               LMA               File off  Algn<br>
  0 .group        00000014  0000000000000000  0000000000000000  00000040  2**2<br>
                  CONTENTS, READONLY, EXCLUDE, GROUP, LINK_ONCE_DISCARD<br>
  1 .text         00000068  0000000000000000  0000000000000000  00000060  2**4<br>
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE<br>
  2 .text.startup 00000080  0000000000000000  0000000000000000  000000d0  2**4<br>
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE<br>
  3 .rodata       00000001  0000000000000000  0000000000000000  00000150  2**0<br>
                  CONTENTS, ALLOC, LOAD, READONLY, DATA<br>
  4 .rodata.str1.16 00000024  0000000000000000  0000000000000000  00000160  2**4<br>
                  CONTENTS, ALLOC, LOAD, READONLY, DATA<br>
  5 .omp_offloading.entries 00000020  0000000000000000  0000000000000000  00000184  2**0<br>
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA<br>
  6 .rodata..omp_offloading.device<wbr>_images 00000020  0000000000000000  0000000000000000  000001a8  2**3<br>
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA<br>
  7 .rodata..omp_offloading.descri<wbr>ptor 00000020  0000000000000000  0000000000000000  000001c8  2**3<br>
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA<br>
  8 __CLANG_OFFLOAD_BUNDLE__openmp<wbr>-x86_64-unknown-linux-gnu 00000588  0000000000000000  0000000000000000  000001f0  2**4<br>
                  CONTENTS, ALLOC, LOAD, READONLY, DATA<br>
  9 __CLANG_OFFLOAD_BUNDLE__host-x<wbr>86_64-unknown-linux-gnu 00000001  0000000000000000  0000000000000000  00000778  2**0<br>
                  CONTENTS, ALLOC, LOAD, READONLY, DATA<br>
 10 .eh_frame     00000098  0000000000000000  0000000000000000  00000780  2**3<br>
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA<br>
 11 .init_array.0 00000008  0000000000000000  0000000000000000  00000818  2**3<br>
                  CONTENTS, ALLOC, LOAD, RELOC, DATA<br>
 12 .comment      00000038  0000000000000000  0000000000000000  00000820  2**0<br>
                  CONTENTS, READONLY<br>
 13 .note.GNU-stack 00000000  0000000000000000  0000000000000000  00000858  2**0<br>
                  CONTENTS, READONLY<div><div class="h5"><br>
<br>
Am 2018-01-11 22:12, schrieb Simone Atzeni:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi Jonas,<br>
<br>
The clang-offload-bundler does not look like it uses the ELF sections<br>
(both the version of trunk and Ykt), it looks like it just concatenate<br>
the object files into one file, but I might be wrong or if not<br>
hopefully this will be changed later.<br>
At the moment, even though offloading to GPUs is not working on Clang,<br>
the driver seems like is doing something different than any other<br>
compiler.<br>
I cced Doru, maybe he can add more about this.<br>
<br>
I am just asking because we are going to add GPUs support on Flang and<br>
of course we want to keep clang and flang compatible.<br>
<br>
Thanks.<br>
Simone<br>
<br>
On Thu, Jan 11, 2018 at 1:00 PM, Jonas Hahnfeld <<a href="mailto:hahnjo@hahnjo.de" target="_blank">hahnjo@hahnjo.de</a>><br>
wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi Simone,<br>
<br>
the same answers as always:<br>
1. Offloading to GPUs is not yet working with Clang trunk.<br>
2. Most of this has already been discussed on the mailing list or<br>
described in publications. In short, clang-offload-bundler should<br>
also use ELF sections for object files. And AFAIK, IBM XL uses the<br>
same mechanisms in most cases.<br>
<br>
Jonas<br>
<br>
Am 2018-01-11 19:15, schrieb Simone Atzeni via cfe-dev:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi all,<br>
<br>
I have been playing with the clang driver to see how it performs<br>
the<br>
compilations for an OpenMP program with target offloading (for<br>
NVidia<br>
GPU).<br>
<br>
I noticed the use of the tool 'clang-offload-bundler' which seems<br>
to<br>
bundle together the object files for the host and for the device.<br>
In particular, if I use -c my foo.o will be a bundle of<br>
foo-x86_64.o<br>
and foo-cuda.o, and at link time it will unbundle the foo.o to<br>
obtain<br>
back the two object files.<br>
<br>
Now, if I put my foo.o for example in a static library clang does<br>
not<br>
work because it does not know how to unbundle the object files<br>
from<br>
the library.<br>
<br>
Other compilers, such as IBM XL create a specific section in the<br>
ELF<br>
to store the device code, in this way we always have one object<br>
file<br>
and there is no need to bundle/unbundle.<br>
Also if a object file/library was compiled with XL it can not be<br>
linked with clang and/or viceversa.<br>
<br>
So, am I doing something wrong, or is this the status of the clang<br>
driver?<br>
Is the clang-offload-bundler the official choice to manage device<br>
code?<br>
If my analysis is correct, what's the workaround?<br>
<br>
Thanks!<br>
Best,<br>
Simone<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
</div></div><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a> [1]<br>
</blockquote></blockquote>
<br>
<br>
<br>
Links:<br>
------<br>
[1] <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</blockquote>
</blockquote></div><br></div>