On Wed, Oct 21, 2015 at 10:33 AM, Ilya Verbin <iver...@gmail.com> wrote: > 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 >
Does linker make AAA writable? If yes, linker does what it is told. -- H.J.
