Hi! On Wed, Jul 15, 2015 at 20:56:50 -0400, Nathan Sidwell wrote: > --- libgcc/offloadstuff.c (revision 225851) > +++ libgcc/offloadstuff.c (working copy) > ... > -void *__offload_func_table[0] > +const void *const __offload_func_table[0] > ... > -void *__offload_var_table[0] > +const void *const __offload_var_table[0]
I've just noticed that this patch + similar change in intelmic-mkoffload.c <https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01452.html> bumps up the filesize of "helloworld" with offloading to MIC from 17KB to 4MB! This happens because .gnu.offload_{funcs,vars} sections in crtoffload{begin,end}.o now doesn't have WRITE flag, but the same sections produced by omp_finish_file has it. When linker joins writable + nonwritable sections from several objects, it inserts some weird 2MB offset into the final binary. I.e. now there are 2 such offsets: one in the host binary and one in the MIC target image, hence 4MB. I haven't investigated how it happens, because I thing it's bad idea to join sections with different flags. But we can't make .gnu.offload_{funcs,vars} in omp_finish_file also readonly, because in case of shared libraries there are R_X86_64_RELATIVE relocations, which make these sections writable. So, I guess we need to remove all consts to make these sections writable in all objects. H.J., Maybe linker should print some warning about joining writable + nonwritable sections? Here is a simple testcase: $ cat t1.s .section ".AAA", "a" .long 0x12345678 $ cat t2.s .section ".AAA", "wa" .long 0x12345678 $ as t1.s -o t1.o $ as t2.s -o t2.o $ ld -shared t1.o t2.o $ ls -lh a.out 2.1M a.out -- Ilya
