On Wed, Feb 10, 2016 at 08:19:34PM +0300, Ilya Verbin wrote:
> This patch adds crtoffload{begin,end}.o to all -fopenmp programs, if they
> exist.
> I couldn't think of a better solution...
> Tested using the testcase from the previous mail, e.g.:
>
> $ gcc -DNUM=1 -c -fopenmp test.c -o obj1.o
> $ gcc -DNUM=2 -c -fopenmp test.c -o obj2.o
> $ gcc -DNUM=3 -c -fopenmp test.c -o obj3.o
> $ gcc -DNUM=4 -c -fopenmp test.c -o obj4.o -flto
> $ gcc -DNUM=5 -c -fopenmp test.c -o obj5.o
> $ gcc -DNUM=6 -c -fopenmp test.c -o obj6.o -flto
> $ gcc -DNUM=7 -c -fopenmp test.c -o obj7.o
> $ gcc-ar -cvq libtest.a obj3.o obj4.o obj5.o
> $ gcc -fopenmp main.c obj1.o obj2.o libtest.a obj6.o obj7.o
>
> And other combinations.
Looking at this, I think I have no problem with crtoffloadbegin.o being
included in all -fopenmp/-fopenacc linked programs/shared libraries,
that just defines the symbols and nothing else.
I have no problem with the
__offload_funcs_end/__offload_vars_end part of crtoffloadend.o being
included too.
But, I really don't like __OFFLOAD_TABLE__ being added to all programs, that
wastes real space in data (rodata or relro?) section, and dynamic
relocations.
So, perhaps, can we split offloadstuff.c into 3 objects instead of 2,
crtoffload{begin,end,table}.o*, where the last one would be what
defines __OFFLOAD_TABLE__, and add the last one only by the linker
plugin/lto-wrapper/whatever, if any input objects had any offloading stuff
in it?
Jakub
