This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Constify host-side offload data`
- From: Ilya Verbin <iverbin at gmail dot com>
- To: Nathan Sidwell <nathan at acm dot org>, Bernd Schmidt <bschmidt at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Kirill Yukhin <kirill dot yukhin at gmail dot com>
- Date: Wed, 21 Oct 2015 20:33:50 +0300
- Subject: Re: Constify host-side offload data`
- Authentication-results: sourceware.org; auth=none
- References: <55A70152 dot 8010702 at acm dot org>
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