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...@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
