Constify host-side offload data`

Constify host-side offload data`

[Nathan Sidwell]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

This patch constifies the objects involved in describing the host-side 
offloading information.  Probably won't make much difference in executable 
layout because of relocations, but at least allows them to be put into 
.rel.rodata, and makes it clear the objects aren't modified.

ok for trunk?

nathan

[-- Attachment #2: host-const.patch --]
[-- Type: text/x-patch, Size: 5898 bytes --]

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,

Re: Constify host-side offload data`

[Ilya Verbin]

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

Re: Constify host-side offload data`

[Nathan Sidwell]

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

Re: Constify host-side offload data`

[Jakub Jelinek]

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

Re: Constify host-side offload data`

[Ilya Verbin]

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

Re: Constify host-side offload data`

[H.J. Lu]

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.


-- 
H.J.

Re: Constify host-side offload data`

[Ilya Verbin]

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

Re: Constify host-side offload data`

[Nathan Sidwell]

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

Re: Constify host-side offload data`

[H.J. Lu]

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.

-- 
H.J.

Re: Constify host-side offload data`

[Ilya Verbin]

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

Re: Constify host-side offload data`

[H.J. Lu]

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.


-- 
H.J.

Re: Constify host-side offload data`

[Ilya Verbin]

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