| Message ID | 55A70152.8010702@acm.org |
|---|---|
| State | New |
| Headers | show |
On Wed, Jul 15, 2015 at 20:56:50 -0400, Nathan Sidwell wrote: > Index: gcc/config/nvptx/mkoffload.c > =================================================================== > - fprintf (out, "extern void *__OFFLOAD_TABLE__[];\n\n"); > + fprintf (out, "extern const void *conat __OFFLOAD_TABLE__[];\n\n"); Here is a typo. -- Ilya
On 07/16/15 07:41, Ilya Verbin wrote: > On Wed, Jul 15, 2015 at 20:56:50 -0400, Nathan Sidwell wrote: >> Index: gcc/config/nvptx/mkoffload.c >> =================================================================== >> - fprintf (out, "extern void *__OFFLOAD_TABLE__[];\n\n"); >> + fprintf (out, "extern const void *conat __OFFLOAD_TABLE__[];\n\n"); > > Here is a typo. Thanks, caught that myself too. testing shows the patch ok for x86-linux/ptx nathan
On Thu, Jul 16, 2015 at 08:20:53AM -0400, Nathan Sidwell wrote: > On 07/16/15 07:41, Ilya Verbin wrote: > >On Wed, Jul 15, 2015 at 20:56:50 -0400, Nathan Sidwell wrote: > >>Index: gcc/config/nvptx/mkoffload.c > >>=================================================================== > >>- fprintf (out, "extern void *__OFFLOAD_TABLE__[];\n\n"); > >>+ fprintf (out, "extern const void *conat __OFFLOAD_TABLE__[];\n\n"); > > > >Here is a typo. > > Thanks, caught that myself too. testing shows the patch ok for x86-linux/ptx Ok for trunk with that change. Jakub
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
On Wed, Oct 21, 2015 at 10:33 AM, Ilya Verbin <iverbin@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.
On Wed, Oct 21, 2015 at 10:38:10 -0700, H.J. Lu wrote: > On Wed, Oct 21, 2015 at 10:33 AM, Ilya Verbin <iverbin@gmail.com> wrote: > > 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. Yes, it makes it writable, but why it also makes this? [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .hash HASH 00000000000000b0 000000b0 0000000000000028 0000000000000004 A 2 0 8 [ 2] .dynsym DYNSYM 00000000000000d8 000000d8 0000000000000078 0000000000000018 A 3 2 8 [ 3] .dynstr STRTAB 0000000000000150 00000150 0000000000000019 0000000000000000 A 0 0 1 [ 4] .AAA PROGBITS 0000000000000169 00000169 0000000000000008 0000000000000000 WA 0 0 1 [ 5] .eh_frame PROGBITS 0000000000000178 00000178 0000000000000000 0000000000000000 A 0 0 8 [ 6] .dynamic DYNAMIC 0000000000200178 00200178 <-- ??? 00000000000000b0 0000000000000010 WA 3 0 8 [ 7] .shstrtab STRTAB 0000000000000000 00200380 0000000000000049 0000000000000000 0 0 1 [ 8] .symtab SYMTAB 0000000000000000 00200228 0000000000000120 0000000000000018 9 9 8 [ 9] .strtab STRTAB 0000000000000000 00200348 0000000000000038 0000000000000000 0 0 1 -- Ilya
On Wed, Oct 21, 2015 at 10:42 AM, Ilya Verbin <iverbin@gmail.com> wrote: > On Wed, Oct 21, 2015 at 10:38:10 -0700, H.J. Lu wrote: >> On Wed, Oct 21, 2015 at 10:33 AM, Ilya Verbin <iverbin@gmail.com> wrote: >> > 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. > > Yes, it makes it writable, but why it also makes this? > > [Nr] Name Type Address Offset > Size EntSize Flags Link Info Align > [ 0] NULL 0000000000000000 00000000 > 0000000000000000 0000000000000000 0 0 0 > [ 1] .hash HASH 00000000000000b0 000000b0 > 0000000000000028 0000000000000004 A 2 0 8 > [ 2] .dynsym DYNSYM 00000000000000d8 000000d8 > 0000000000000078 0000000000000018 A 3 2 8 > [ 3] .dynstr STRTAB 0000000000000150 00000150 > 0000000000000019 0000000000000000 A 0 0 1 > [ 4] .AAA PROGBITS 0000000000000169 00000169 > 0000000000000008 0000000000000000 WA 0 0 1 > [ 5] .eh_frame PROGBITS 0000000000000178 00000178 > 0000000000000000 0000000000000000 A 0 0 8 > [ 6] .dynamic DYNAMIC 0000000000200178 00200178 <-- ??? > 00000000000000b0 0000000000000010 WA 3 0 8 > [ 7] .shstrtab STRTAB 0000000000000000 00200380 > 0000000000000049 0000000000000000 0 0 1 > [ 8] .symtab SYMTAB 0000000000000000 00200228 > 0000000000000120 0000000000000018 9 9 8 > [ 9] .strtab STRTAB 0000000000000000 00200348 > 0000000000000038 0000000000000000 0 0 1 > Linker groups input sections by section name and ors section flags.
On 10/21/15 13:33, Ilya Verbin wrote: > Hi! > 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. That is a strange insertion of padding. Joining sections with different flags, is IIUC, perfectly fine. > 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, Um, I thought they had absolute relocs, and thus were relro, but ICBW. > which make these sections writable. So, I guess we need to remove all consts to > make these sections writable in all objects. That seems like the prudent path. nathan
On Wed, Oct 21, 2015 at 10:44:56 -0700, H.J. Lu wrote: > On Wed, Oct 21, 2015 at 10:42 AM, Ilya Verbin <iverbin@gmail.com> wrote: > > On Wed, Oct 21, 2015 at 10:38:10 -0700, H.J. Lu wrote: > >> On Wed, Oct 21, 2015 at 10:33 AM, Ilya Verbin <iverbin@gmail.com> wrote: > >> > 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. > > > > Yes, it makes it writable, but why it also makes this? > > > > [Nr] Name Type Address Offset > > Size EntSize Flags Link Info Align > > [ 0] NULL 0000000000000000 00000000 > > 0000000000000000 0000000000000000 0 0 0 > > [ 1] .hash HASH 00000000000000b0 000000b0 > > 0000000000000028 0000000000000004 A 2 0 8 > > [ 2] .dynsym DYNSYM 00000000000000d8 000000d8 > > 0000000000000078 0000000000000018 A 3 2 8 > > [ 3] .dynstr STRTAB 0000000000000150 00000150 > > 0000000000000019 0000000000000000 A 0 0 1 > > [ 4] .AAA PROGBITS 0000000000000169 00000169 > > 0000000000000008 0000000000000000 WA 0 0 1 > > [ 5] .eh_frame PROGBITS 0000000000000178 00000178 > > 0000000000000000 0000000000000000 A 0 0 8 > > [ 6] .dynamic DYNAMIC 0000000000200178 00200178 <-- ??? > > 00000000000000b0 0000000000000010 WA 3 0 8 > > [ 7] .shstrtab STRTAB 0000000000000000 00200380 > > 0000000000000049 0000000000000000 0 0 1 > > [ 8] .symtab SYMTAB 0000000000000000 00200228 > > 0000000000000120 0000000000000018 9 9 8 > > [ 9] .strtab STRTAB 0000000000000000 00200348 > > 0000000000000038 0000000000000000 0 0 1 > > > > Linker groups input sections by section name and ors section > flags. Could you please help figure out how this number 0x200178 is calculated? ld -verbose doesn't show anything helpful. It seems that something goes wrong during section-to-segment mapping, because when both .AAA have "wa" flags, we got small binary with 2 LOAD segments: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x00000000000001a8 0x00000000000001a8 R 200000 LOAD 0x00000000000001a8 0x00000000002001a8 0x00000000002001a8 0x00000000000000b8 0x00000000000000b8 RW 200000 But when one .AAA has "a" flag, and another .AAA has "wa" flag, we got huge binary with only one big LOAD segment: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000200228 0x0000000000200228 RW 200000 BTW, gold produces small binary in both cases. Thanks, -- Ilya
On Thu, Oct 22, 2015 at 7:11 AM, Ilya Verbin <iverbin@gmail.com> wrote: > On Wed, Oct 21, 2015 at 10:44:56 -0700, H.J. Lu wrote: >> On Wed, Oct 21, 2015 at 10:42 AM, Ilya Verbin <iverbin@gmail.com> wrote: >> > On Wed, Oct 21, 2015 at 10:38:10 -0700, H.J. Lu wrote: >> >> On Wed, Oct 21, 2015 at 10:33 AM, Ilya Verbin <iverbin@gmail.com> wrote: >> >> > 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. >> > >> > Yes, it makes it writable, but why it also makes this? >> > >> > [Nr] Name Type Address Offset >> > Size EntSize Flags Link Info Align >> > [ 0] NULL 0000000000000000 00000000 >> > 0000000000000000 0000000000000000 0 0 0 >> > [ 1] .hash HASH 00000000000000b0 000000b0 >> > 0000000000000028 0000000000000004 A 2 0 8 >> > [ 2] .dynsym DYNSYM 00000000000000d8 000000d8 >> > 0000000000000078 0000000000000018 A 3 2 8 >> > [ 3] .dynstr STRTAB 0000000000000150 00000150 >> > 0000000000000019 0000000000000000 A 0 0 1 >> > [ 4] .AAA PROGBITS 0000000000000169 00000169 >> > 0000000000000008 0000000000000000 WA 0 0 1 >> > [ 5] .eh_frame PROGBITS 0000000000000178 00000178 >> > 0000000000000000 0000000000000000 A 0 0 8 >> > [ 6] .dynamic DYNAMIC 0000000000200178 00200178 <-- ??? >> > 00000000000000b0 0000000000000010 WA 3 0 8 >> > [ 7] .shstrtab STRTAB 0000000000000000 00200380 >> > 0000000000000049 0000000000000000 0 0 1 >> > [ 8] .symtab SYMTAB 0000000000000000 00200228 >> > 0000000000000120 0000000000000018 9 9 8 >> > [ 9] .strtab STRTAB 0000000000000000 00200348 >> > 0000000000000038 0000000000000000 0 0 1 >> > >> >> Linker groups input sections by section name and ors section >> flags. > > Could you please help figure out how this number 0x200178 is calculated? > ld -verbose doesn't show anything helpful. It seems that something goes wrong > during section-to-segment mapping, because when both .AAA have "wa" flags, we > got small binary with 2 LOAD segments: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 > 0x00000000000001a8 0x00000000000001a8 R 200000 > LOAD 0x00000000000001a8 0x00000000002001a8 0x00000000002001a8 > 0x00000000000000b8 0x00000000000000b8 RW 200000 > > But when one .AAA has "a" flag, and another .AAA has "wa" flag, we got huge > binary with only one big LOAD segment: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 > 0x0000000000200228 0x0000000000200228 RW 200000 > > BTW, gold produces small binary in both cases. > Please open a binutils bug with a testcase.
On Thu, Oct 22, 2015 at 07:35:55 -0700, H.J. Lu wrote: > On Thu, Oct 22, 2015 at 7:11 AM, Ilya Verbin <iverbin@gmail.com> wrote: > > On Wed, Oct 21, 2015 at 10:44:56 -0700, H.J. Lu wrote: > >> On Wed, Oct 21, 2015 at 10:42 AM, Ilya Verbin <iverbin@gmail.com> wrote: > >> > On Wed, Oct 21, 2015 at 10:38:10 -0700, H.J. Lu wrote: > >> >> On Wed, Oct 21, 2015 at 10:33 AM, Ilya Verbin <iverbin@gmail.com> wrote: > >> >> > 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. > >> > > >> > Yes, it makes it writable, but why it also makes this? > >> > > >> > [Nr] Name Type Address Offset > >> > Size EntSize Flags Link Info Align > >> > [ 0] NULL 0000000000000000 00000000 > >> > 0000000000000000 0000000000000000 0 0 0 > >> > [ 1] .hash HASH 00000000000000b0 000000b0 > >> > 0000000000000028 0000000000000004 A 2 0 8 > >> > [ 2] .dynsym DYNSYM 00000000000000d8 000000d8 > >> > 0000000000000078 0000000000000018 A 3 2 8 > >> > [ 3] .dynstr STRTAB 0000000000000150 00000150 > >> > 0000000000000019 0000000000000000 A 0 0 1 > >> > [ 4] .AAA PROGBITS 0000000000000169 00000169 > >> > 0000000000000008 0000000000000000 WA 0 0 1 > >> > [ 5] .eh_frame PROGBITS 0000000000000178 00000178 > >> > 0000000000000000 0000000000000000 A 0 0 8 > >> > [ 6] .dynamic DYNAMIC 0000000000200178 00200178 <-- ??? > >> > 00000000000000b0 0000000000000010 WA 3 0 8 > >> > [ 7] .shstrtab STRTAB 0000000000000000 00200380 > >> > 0000000000000049 0000000000000000 0 0 1 > >> > [ 8] .symtab SYMTAB 0000000000000000 00200228 > >> > 0000000000000120 0000000000000018 9 9 8 > >> > [ 9] .strtab STRTAB 0000000000000000 00200348 > >> > 0000000000000038 0000000000000000 0 0 1 > >> > > >> > >> Linker groups input sections by section name and ors section > >> flags. > > > > Could you please help figure out how this number 0x200178 is calculated? > > ld -verbose doesn't show anything helpful. It seems that something goes wrong > > during section-to-segment mapping, because when both .AAA have "wa" flags, we > > got small binary with 2 LOAD segments: > > Type Offset VirtAddr PhysAddr > > FileSiz MemSiz Flags Align > > LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 > > 0x00000000000001a8 0x00000000000001a8 R 200000 > > LOAD 0x00000000000001a8 0x00000000002001a8 0x00000000002001a8 > > 0x00000000000000b8 0x00000000000000b8 RW 200000 > > > > But when one .AAA has "a" flag, and another .AAA has "wa" flag, we got huge > > binary with only one big LOAD segment: > > Type Offset VirtAddr PhysAddr > > FileSiz MemSiz Flags Align > > LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 > > 0x0000000000200228 0x0000000000200228 RW 200000 > > > > BTW, gold produces small binary in both cases. > > > > Please open a binutils bug with a testcase. Done: https://sourceware.org/bugzilla/show_bug.cgi?id=19162 -- Ilya
2015-07-15 Nathan Sidwell <nathan@codesourcery.com> gcc/ * config/nvptx/mkoffload.c (process): Constify host data. * config/i386/intelmic-mkoffload.c (generate_target_descr_file): Constify host data. (generate_host_descr_file): Likewise. libgomp/ * target.c (struct_offload_image_descr): Constify host_table. (gomp_offload_image_to_device): Likewise. (GOMP_offload_register, GOMP_offload_unregister): Likewise. libgcc/ * offloadstuff.c: Constify host data. Index: gcc/config/nvptx/mkoffload.c =================================================================== --- gcc/config/nvptx/mkoffload.c (revision 225851) +++ gcc/config/nvptx/mkoffload.c (working copy) @@ -870,12 +870,13 @@ process (FILE *in, FILE *out) fprintf (out, "#ifdef __cplusplus\n" "extern \"C\" {\n" "#endif\n"); - fprintf (out, "extern void GOMP_offload_register (void *, int, void *);\n"); + fprintf (out, "extern void GOMP_offload_register" + " (const void *, int, void *);\n"); fprintf (out, "#ifdef __cplusplus\n" "}\n" "#endif\n"); - fprintf (out, "extern void *__OFFLOAD_TABLE__[];\n\n"); + fprintf (out, "extern const void *conat __OFFLOAD_TABLE__[];\n\n"); fprintf (out, "static __attribute__((constructor)) void init (void)\n{\n"); fprintf (out, " GOMP_offload_register (__OFFLOAD_TABLE__, %d,\n", GOMP_DEVICE_NVIDIA_PTX); Index: gcc/config/i386/intelmic-mkoffload.c =================================================================== --- gcc/config/i386/intelmic-mkoffload.c (revision 225851) +++ gcc/config/i386/intelmic-mkoffload.c (working copy) @@ -252,7 +252,7 @@ generate_target_descr_file (const char * "__attribute__ ((__used__, visibility (\"hidden\"),\n" "section (\".gnu.offload_vars\"))) = { };\n\n" - "void *__OFFLOAD_TARGET_TABLE__[]\n" + "void const *const __OFFLOAD_TARGET_TABLE__[]\n" "__attribute__ ((__used__, visibility (\"hidden\"))) = {\n" " &__offload_func_table, &__offload_funcs_end,\n" " &__offload_var_table, &__offload_vars_end\n" @@ -338,7 +338,7 @@ generate_host_descr_file (const char *ho fatal_error (input_location, "cannot open '%s'", src_filename); fprintf (src_file, - "extern void *__OFFLOAD_TABLE__;\n" + "extern const void *const __OFFLOAD_TABLE__[];\n" "extern void *__offload_image_intelmic_start;\n" "extern void *__offload_image_intelmic_end;\n\n" @@ -350,11 +350,11 @@ generate_host_descr_file (const char *ho "#ifdef __cplusplus\n" "extern \"C\"\n" "#endif\n" - "void GOMP_offload_register (void *, int, void *);\n" + "void GOMP_offload_register (const void *, int, void *);\n" "#ifdef __cplusplus\n" "extern \"C\"\n" "#endif\n" - "void GOMP_offload_unregister (void *, int, void *);\n\n" + "void GOMP_offload_unregister (const void *, int, void *);\n\n" "__attribute__((constructor))\n" "static void\n" Index: libgomp/target.c =================================================================== --- libgomp/target.c (revision 225851) +++ libgomp/target.c (working copy) @@ -57,7 +57,7 @@ static gomp_mutex_t register_lock; pointer to target data. */ struct offload_image_descr { enum offload_target_type type; - void *host_table; + const void *host_table; void *target_data; }; @@ -642,7 +642,7 @@ gomp_update (struct gomp_device_descr *d static void gomp_offload_image_to_device (struct gomp_device_descr *devicep, - void *host_table, void *target_data, + const void *host_table, void *target_data, bool is_register_lock) { void **host_func_table = ((void ***) host_table)[0]; @@ -730,7 +730,8 @@ gomp_offload_image_to_device (struct gom the target, and TARGET_DATA needed by target plugin. */ void -GOMP_offload_register (void *host_table, enum offload_target_type target_type, +GOMP_offload_register (const void *host_table, + enum offload_target_type target_type, void *target_data) { int i; @@ -764,7 +765,8 @@ GOMP_offload_register (void *host_table, the target, and TARGET_DATA needed by target plugin. */ void -GOMP_offload_unregister (void *host_table, enum offload_target_type target_type, +GOMP_offload_unregister (const void *host_table, + enum offload_target_type target_type, void *target_data) { void **host_func_table = ((void ***) host_table)[0]; Index: libgcc/offloadstuff.c =================================================================== --- libgcc/offloadstuff.c (revision 225851) +++ libgcc/offloadstuff.c (working copy) @@ -46,10 +46,10 @@ see the files COPYING3 and COPYING.RUNTI #ifdef CRT_BEGIN #if defined(HAVE_GAS_HIDDEN) && defined(ENABLE_OFFLOADING) -void *__offload_func_table[0] +const void *const __offload_func_table[0] __attribute__ ((__used__, visibility ("hidden"), section (OFFLOAD_FUNC_TABLE_SECTION_NAME))) = { }; -void *__offload_var_table[0] +const void *const __offload_var_table[0] __attribute__ ((__used__, visibility ("hidden"), section (OFFLOAD_VAR_TABLE_SECTION_NAME))) = { }; #endif @@ -57,17 +57,17 @@ void *__offload_var_table[0] #elif defined CRT_END #if defined(HAVE_GAS_HIDDEN) && defined(ENABLE_OFFLOADING) -void *__offload_funcs_end[0] +const void *const __offload_funcs_end[0] __attribute__ ((__used__, visibility ("hidden"), section (OFFLOAD_FUNC_TABLE_SECTION_NAME))) = { }; -void *__offload_vars_end[0] +const void *const __offload_vars_end[0] __attribute__ ((__used__, visibility ("hidden"), section (OFFLOAD_VAR_TABLE_SECTION_NAME))) = { }; -extern void *__offload_func_table[]; -extern void *__offload_var_table[]; +extern const void *const __offload_func_table[]; +extern const void *const __offload_var_table[]; -void *__OFFLOAD_TABLE__[] +const void *const __OFFLOAD_TABLE__[] __attribute__ ((__visibility__ ("hidden"))) = { &__offload_func_table, &__offload_funcs_end,