[Bug target/50166] .init_array/.fini_array support doesn't work on Solaris

["ro at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50166

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
            Version|unknown                     |4.7.0
   Last reconfirmed|                            |2011-08-26
          Component|go                          |target
                 CC|                            |hjl at gcc dot gnu.org, ian
                   |                            |at airs dot com
         AssignedTo|ian at airs dot com         |ro at gcc dot gnu.org
     Ever Confirmed|0                           |1
            Summary|ICE in go1: SEGV on Solaris |.init_array/.fini_array
                   |10/x86                      |support doesn't work on
                   |                            |Solaris
   Target Milestone|---                         |4.7.0

--- Comment #3 from Rainer Orth <ro at gcc dot gnu.org> 2011-08-26 14:23:51 UTC ---
The reghunt identified the culprit patch:

2011-08-20  H.J. Lu  <hongjiu.lu@intel.com>

    PR other/46770
    * config.gcc (tm_file): Add initfini-array.h if
    .init_arrary/.fini_array are supported.
[...]

The problem is that the test spuriously succeeds, but .init_array/.fini_array
support doesn't work as assumed:

If I add debug printf's to the ctors, dtors, and main, I find that only main
runs.

One problem with the test is that it fails to check that any of the destructors
have run.  Unfortunately, it doesn't even work on CentOS 5.5 with mainline
gcc, gas and gld 2.21:

ctor1007 entry: count = 0
Aborted

so I'm not completely sure how it is supposed to work.  At the very least, we
need

diff --git a/gcc/acinclude.m4 b/gcc/acinclude.m4
--- a/gcc/acinclude.m4
+++ b/gcc/acinclude.m4
@@ -477,6 +477,8 @@ void (*const dtors65535[]) ()
 int
 main ()
 {
+  if (count != 65535)
+    abort ();
   return 0;
 }
 #endif

or whatever value count is supposed to have here.

This patch at least allowed a successfull i386-pc-solaris2.11 bootstrap.

As for other issues with the testcase:

void (*const ctors65535[]) ()
  __attribute__ ((section (".ctors"), aligned (sizeof (void *))))
  = { ctor65535 };

leads to

       .section        .ctors,"a",@progbits

while using __attribute__ ((constructor) instead works.  It has

       .section        .ctors,"aw",@progbits

crtbegin.o and crtend.o already have the latter form, and Sun ld only merges
input sections if all of sh_name, sh_flags, and sh_type match.  The resulting
executable has two different .ctors sections, as can be seen with 

> elfdump -N .ctors -c initfini      

Section Header[24]:  sh_name: .ctors
    sh_addr:      0x8051084       sh_flags:   [ SHF_ALLOC ]
    sh_size:      0x4             sh_type:    [ SHT_PROGBITS ]
    sh_offset:    0x1084          sh_entsize: 0
    sh_link:      0               sh_info:    0
    sh_addralign: 0x4       

Section Header[32]:  sh_name: .ctors
    sh_addr:      0x8061260       sh_flags:   [ SHF_WRITE SHF_ALLOC ]
    sh_size:      0x8             sh_type:    [ SHT_PROGBITS ]
    sh_offset:    0x1260          sh_entsize: 0
    sh_link:      0               sh_info:    0
    sh_addralign: 0x4       

I don't know why __attribute__ ((section(".ctors)) creates a read-only section;
there seems no way to set a section's SECTION_WRITE flag.

The other problem with the testcase is the use of .ctors.<N> sections.  AFAICT
the coalescing of .ctors.<N> sections into .ctors (and similar behavior for
.dtors.<N>, .init_array.<N> and .fini_array.<N>) is a GNU ld feature or
implementation detail not called for by the ELF gABI.  Please point out where
this is specified if I'm wrong.  Certainly, Sun ld (and SGI ld for that matter)
don't do this.

  Rainer