Serious regressions due to newlib's HAVE_INITFINI_ARRAY (Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237))

2012-02-22 Thread Ulrich Weigand 
Jakub Jelinek wrote:

   PR bootstrap/50237
   * config/initfini-array.h: Guard content of the header
   with #ifdef HAVE_INITFINI_ARRAY.
   * configure.ac: Move gcc_AC_INITFINI_ARRAY much later into the file.
   Add initfini-array.h to tm_file here.
   * acinclude.m4 (gcc_AC_INITFINI_ARRAY): For non-ia64 do a linker
   test.
   * config.gcc: Don't add initfini-array.h to tm_file here.
   * configure: Regenerated.

This patch causes serious regressions on spu-elf, and presumably other
newlib targets.  The effect of the patch is to switch GCC to use
.init_array/.fini_array instead of .init/.fini; but the former is
not actually supported by newlib startup code (at least on SPU and
most other platforms supported by newlib), so that constructors and
destructors end up simply being ignored.

This occurs due to combination of GCC configury changes introduced
by the patch and a bug in newlib system headers.  Before the patch,
initfini-array.h was not included into tm.h when building a cross-
compiler to spu-elf, and after the patch it is.  Now, the patch
also inserts a #ifdef HAVE_INITFINI_ARRAY check, and the configure
check does not define this macro for cross-compilers, so in theory
that should not cause any change in behaviour.

However, the macro HAVE_INITFINI_ARRAY is defined anyway; this
definition is done by an internal newlib.h header that is pulled
in via the stdio.h include in GCC's tsystem.h.  [ This is clearly
a violation of C namespace rules, but this has been the situation
for all newlib releases since about 2005 ... ]

Since initfini-array.h is now pulled in and HAVE_INITFINI_ARRAY
is defined, we get USE_INITFINI_ARRAY defined as well, which
causes the crtstuff files to be build for .init_array support.


Now, I guess the newlib headers should be fixed to no longer
pollute the namespace by defining HAVE_INITFINI_ARRAY.

However, I'm wondering whether there is a way to change
GCC to fix that regression even with existing newlib headers.

For example, I guess GCC configury could rename its instance of
HAVE_INITFINI_ARRAY (maybe define USE_INITFINI_ARRAY to begin
with)?


Any suggestions how to proceed with this welcome!  I'd really
like to see this fixed for 4.7, otherwise the compiler will be
seriously broken ...

Thanks,
Ulrich


-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: Serious regressions due to newlib's HAVE_INITFINI_ARRAY (Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237))

2012-02-22 Thread Jakub Jelinek 
On Wed, Feb 22, 2012 at 03:55:34PM +0100, Ulrich Weigand wrote:
 However, the macro HAVE_INITFINI_ARRAY is defined anyway; this
 definition is done by an internal newlib.h header that is pulled
 in via the stdio.h include in GCC's tsystem.h.  [ This is clearly
 a violation of C namespace rules, but this has been the situation
 for all newlib releases since about 2005 ... ]

Ugh, clearly newlib bug...

 Any suggestions how to proceed with this welcome!  I'd really
 like to see this fixed for 4.7, otherwise the compiler will be
 seriously broken ...

I guess the easiest would be just to rename the gcc HAVE_INITFINI_ARRAY
macro to something else, HAVE_INITFINI_ARRAY_SUPPORT or whatever.

Jakub

Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

2012-02-20 Thread Richard Guenther 
On Fri, Feb 17, 2012 at 2:51 PM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
 Rainer Orth r...@cebitec.uni-bielefeld.de writes:

 Richard Guenther richard.guent...@gmail.com writes:

 I'm not sure about the varasm.c change - it's definitely not a no-op
 (callback will be not set, and the flags will be different).  Certainly

 As I've demonstrated in my response to H.J., the effect with gas is none.

 the current code is inconsistent wrt the priority != DEFAULT_INIT_PRIORITY
 case, not sure why, but you don't make it consistent either because
 you don't change that case to SECTION_NOTYPE either.  I'd be fine

 I didn't find a need for that, but agree that the inconsistency is
 disturbing.  default_section_type_flags suggests that SECTION_NOTYPE
 should be set for .init_array and friends, but it's only used by
 get_named_section.

 with it with both calls using SECTION_NOTYPE, but would like to
 know what the callback difference is about.

 I don't think the callback is needed, which is effectively a

       printf (\t.section\t.init_array);

 Looking at it, this is e.g. wrong for Sun as on SPARC, which requires
 the section name to be in double quotes.

 Here's the revised patch which consistently sets SECTION_NOTYPE.

 Bootstrapped without regressions on i386-pc-solaris2.11 with gas/gld and
 x86_64-unknown-linux-gnu, ok for mainline?

Ok.

Thanks,
Richard.

        Rainer


 2012-01-20  Rainer Orth  r...@cebitec.uni-bielefeld.de

        PR target/50166
        * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Require gcc_SUN_LD_VERSION.
        Define _start.
        Remove -e 0 from $gcc_cv_ld invocation.
        Only use __GLIBC_PREREQ if defined.
        Enable on Solaris since Solaris 8 patch.
        (gcc_SUN_LD_VERSION): New macro.
        * configure.ac (ld_ver) *-*-solaris2*: Refer to
        gcc_SUN_LD_VERSION for version number format.
        * configure: Regenerate.
        * varasm.c (get_elf_initfini_array_priority_section): Set
        SECTION_NOTYPE for non-default priority.
        Use get_section instead of get_unnamed_section to emit
        .init_array/.fini_array with default priority.




 --
 -
 Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

2012-02-17 Thread Rainer Orth 
Rainer Orth r...@cebitec.uni-bielefeld.de writes:

 Richard Guenther richard.guent...@gmail.com writes:

 I'm not sure about the varasm.c change - it's definitely not a no-op
 (callback will be not set, and the flags will be different).  Certainly

 As I've demonstrated in my response to H.J., the effect with gas is none.

 the current code is inconsistent wrt the priority != DEFAULT_INIT_PRIORITY
 case, not sure why, but you don't make it consistent either because
 you don't change that case to SECTION_NOTYPE either.  I'd be fine

 I didn't find a need for that, but agree that the inconsistency is
 disturbing.  default_section_type_flags suggests that SECTION_NOTYPE
 should be set for .init_array and friends, but it's only used by
 get_named_section.

 with it with both calls using SECTION_NOTYPE, but would like to
 know what the callback difference is about.

 I don't think the callback is needed, which is effectively a

   printf (\t.section\t.init_array);

 Looking at it, this is e.g. wrong for Sun as on SPARC, which requires
 the section name to be in double quotes.

Here's the revised patch which consistently sets SECTION_NOTYPE.

Bootstrapped without regressions on i386-pc-solaris2.11 with gas/gld and
x86_64-unknown-linux-gnu, ok for mainline?

Rainer


2012-01-20  Rainer Orth  r...@cebitec.uni-bielefeld.de

PR target/50166
* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Require gcc_SUN_LD_VERSION.
Define _start.
Remove -e 0 from $gcc_cv_ld invocation.
Only use __GLIBC_PREREQ if defined.
Enable on Solaris since Solaris 8 patch.
(gcc_SUN_LD_VERSION): New macro.
* configure.ac (ld_ver) *-*-solaris2*: Refer to
gcc_SUN_LD_VERSION for version number format.
* configure: Regenerate.
* varasm.c (get_elf_initfini_array_priority_section): Set
SECTION_NOTYPE for non-default priority.
Use get_section instead of get_unnamed_section to emit
.init_array/.fini_array with default priority.

# HG changeset patch
# Parent 4dc36b1ff03f2d688613f3edbf1d0724079888d3
Enable initfini array support on Solaris

diff --git a/gcc/acinclude.m4 b/gcc/acinclude.m4
--- a/gcc/acinclude.m4
+++ b/gcc/acinclude.m4
@@ -1,4 +1,5 @@
-dnl Copyright (C) 2005, 2006, 2007, 2008, 2011 Free Software Foundation, Inc.
+dnl Copyright (C) 2005, 2006, 2007, 2008, 2011, 2012
+dnl Free Software Foundation, Inc.
 dnl
 dnl This file is part of GCC.
 dnl
@@ -370,7 +371,8 @@ fi
 fi])
 
 AC_DEFUN([gcc_AC_INITFINI_ARRAY],
-[AC_ARG_ENABLE(initfini-array,
+[AC_REQUIRE([gcc_SUN_LD_VERSION])dnl
+AC_ARG_ENABLE(initfini-array,
 	[  --enable-initfini-array	use .init_array/.fini_array sections],
 	[], [
 AC_CACHE_CHECK(for .preinit_array/.init_array/.fini_array support,
@@ -427,9 +429,11 @@ int (*fp) (void) __attribute__ ((section
 .balign 4
 .byte 'H', 'H', 'H', 'H'
 .text
+.globl _start
+_start:
 EOF
 	  if $gcc_cv_as -o conftest.o conftest.s  /dev/null 21 \
-	  $gcc_cv_ld -e 0 -o conftest conftest.o  /dev/null 21 \
+	  $gcc_cv_ld -o conftest conftest.o  /dev/null 21 \
 	  $gcc_cv_objdump -s -j .init_array conftest \
 		| grep   /dev/null 21 \
 	  $gcc_cv_objdump -s -j .fini_array conftest \
@@ -442,14 +446,38 @@ changequote([,])dnl
 	fi
 	AC_PREPROC_IFELSE([AC_LANG_SOURCE([
 #ifndef __ELF__
-#error Not an ELF OS
+# error Not an ELF OS
 #endif
 #include stdlib.h
-#if defined __GLIBC_PREREQ  __GLIBC_PREREQ (2, 4)
+#if defined __GLIBC_PREREQ
+# if __GLIBC_PREREQ (2, 4)
+# else
+#  error GLIBC 2.4 required
+# endif
 #else
-#error The C library not known to support .init_array/.fini_array
+# if defined __sun__  defined __svr4__
+   /* Solaris ld.so.1 supports .init_array/.fini_array since Solaris 8.  */
+# else
+#  error The C library not known to support .init_array/.fini_array
+# endif
 #endif
-])],, [gcc_cv_initfini_array=no]);;
+])],[
+case ${target} in
+  *-*-solaris2.8*)
+	# .init_array/.fini_array support was introduced in Solaris 8
+	# patches 109147-08 (sparc) and 109148-08 (x86).  Since ld.so.1 and
+	# ld are guaranteed to be updated in lockstep, we can check ld -V
+	# instead.  Unfortunately, proper ld version numbers were only
+	# introduced in rev. -14, so we check for that.
+  	if test $gcc_cv_sun_ld_vers_minor -lt 272; then
+	  gcc_cv_initfini_array=no
+	fi
+  ;;
+  *-*-solaris2.9* | *-*-solaris2.1[[0-9]]*)
+# .init_array/.fini_array support is present since Solaris 9 FCS.
+;;
+esac
+], [gcc_cv_initfini_array=no]);;
 esac
   else
 AC_MSG_CHECKING(cross compile... guessing)
@@ -569,6 +597,43 @@ if test $[$2] = yes; then
   $7
 fi])])
 
+dnl gcc_SUN_LD_VERSION
+dnl
+dnl Determines Sun linker version numbers, setting gcc_cv_sun_ld_vers to
+dnl the complete version number and gcc_cv_sun_ld_vers_{major, minor} to
+dnl the corresponding fields.
+dnl
+dnl ld and ld.so.1 are guaranteed to be updated in lockstep, so ld version
+dnl numbers can be used in ld.so.1 feature

Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

2012-02-16 Thread Richard Guenther 
On Wed, Feb 15, 2012 at 6:09 PM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
 Paolo Bonzini bonz...@gnu.org writes:

 This must be a separate macro in acinclude.m4 that is AC_REQUIREd from
 gcc_AC_INITFINI_ARRAY.

 Here's an updated patch that does so.  During testing, I found one
 additional complication, though.  With the Sun as/GNU ld combination on
 Solaris 11/x86, after the bootstrap had completed, all programs linked
 against libgcc_s.so.1 SEGVed with a stacktrace like this:

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 1 (LWP 1)]
 0x2000 in ?? ()
 (gdb) where
 #0  0x2000 in ?? ()
 #1  0xfefcd73f in call_array () from /usr/lib/ld.so.1
 #2  0xfefcd8bd in call_init () from /usr/lib/ld.so.1
 #3  0xfefcc8e1 in setup () from /usr/lib/ld.so.1
 #4  0xfefdcfd8 in _setup () from /usr/lib/ld.so.1
 #5  0xfefc0674 in _rt_boot () from /usr/lib/ld.so.1
 #6  0x0804796c in ?? ()
 #7  0x08047ab0 in ?? ()
 Backtrace stopped: previous frame inner to this frame (corrupt stack?)

 The problem turned out to be that with

        .section        .init_array

 as generates

 Section Header[5]:  sh_name: .init_array
    sh_addr:      0               sh_flags:   0
    sh_size:      0x4             sh_type:    [ SHT_PROGBITS ]
    sh_offset:    0x344           sh_entsize: 0
    sh_link:      0               sh_info:    0
    sh_addralign: 0x4

 i.e. empty sh_flags.  gld seems to mishandle this, since the
 corresponding .initarray entry is bad, as can be seen with runtime
 linker debugging:

 $ LD_DEBUG=init LD_PRELOAD=./libgcc_s.so.1 ls
 [...]
 02032: 1: calling .initarray[0]:0xfed77100: ./libgcc_s.so.1
 02032: 1: calling .initarray[1]:0x2000: ./libgcc_s.so.1
 Segmentation Fault

 If I change the above to

        .section        .init_array,aw,@progbits

 everything works fine with as/gld, but breaks again with gas/gld since
 gas warns about @progbits here.  It turned out that

        .section        .init_array,aw

 is fine with both assemblers, while as doesn't understand @init_array.
 That's what the patch below uses.

 Can you test Linux too?  The change of -e0 looks good, but I'd rather check
 on the actual system.

 This patch has been bootstrapped on i386-pc-solaris2.{8, 9, 10, 11} with
 as/ld, gas/ld and gas/gld, i386-pc-solaris2.11 with as/gld, as well as
 x86_64-unknown-linux-gnu, correctly detecting .init_array etc. support
 on the gld configurations.  It was also included with
 sparc-sun-solaris2.* bootstraps, but even with gas/gld the configure
 test fails.  I've got to investigate that separately.

I'm not sure about the varasm.c change - it's definitely not a no-op
(callback will be not set, and the flags will be different).  Certainly
the current code is inconsistent wrt the priority != DEFAULT_INIT_PRIORITY
case, not sure why, but you don't make it consistent either because
you don't change that case to SECTION_NOTYPE either.  I'd be fine
with it with both calls using SECTION_NOTYPE, but would like to
know what the callback difference is about.

HJ, can you shed some light on this?

Thx,
Richard.

 Ok for mainline now?

 Thanks.
        Rainer


 2012-01-20  Rainer Orth  r...@cebitec.uni-bielefeld.de

        PR target/50166
        * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Require gcc_SUN_LD_VERSION.
        Define _start.
        Remove -e 0 from $gcc_cv_ld invocation.
        Only use __GLIBC_PREREQ if defined.
        Enable on Solaris since Solaris 8 patch.
        (gcc_SUN_LD_VERSION): New macro.
        * configure.ac (ld_ver) *-*-solaris2*: Refer to
        gcc_SUN_LD_VERSION for version number format.
        * configure: Regenerate.
        * varasm.c (get_elf_initfini_array_priority_section): Use
        get_section instead of get_unnamed_section to emit
        .init_array/.fini_array with default priority.



 --
 -
 Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

2012-02-16 Thread H.J. Lu 
On Thu, Feb 16, 2012 at 1:32 AM, Richard Guenther
richard.guent...@gmail.com wrote:
 On Wed, Feb 15, 2012 at 6:09 PM, Rainer Orth
 r...@cebitec.uni-bielefeld.de wrote:
 Paolo Bonzini bonz...@gnu.org writes:

 This must be a separate macro in acinclude.m4 that is AC_REQUIREd from
 gcc_AC_INITFINI_ARRAY.

 Here's an updated patch that does so.  During testing, I found one
 additional complication, though.  With the Sun as/GNU ld combination on
 Solaris 11/x86, after the bootstrap had completed, all programs linked
 against libgcc_s.so.1 SEGVed with a stacktrace like this:

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 1 (LWP 1)]
 0x2000 in ?? ()
 (gdb) where
 #0  0x2000 in ?? ()
 #1  0xfefcd73f in call_array () from /usr/lib/ld.so.1
 #2  0xfefcd8bd in call_init () from /usr/lib/ld.so.1
 #3  0xfefcc8e1 in setup () from /usr/lib/ld.so.1
 #4  0xfefdcfd8 in _setup () from /usr/lib/ld.so.1
 #5  0xfefc0674 in _rt_boot () from /usr/lib/ld.so.1
 #6  0x0804796c in ?? ()
 #7  0x08047ab0 in ?? ()
 Backtrace stopped: previous frame inner to this frame (corrupt stack?)

 The problem turned out to be that with

        .section        .init_array

 as generates

 Section Header[5]:  sh_name: .init_array
    sh_addr:      0               sh_flags:   0
    sh_size:      0x4             sh_type:    [ SHT_PROGBITS ]
    sh_offset:    0x344           sh_entsize: 0
    sh_link:      0               sh_info:    0
    sh_addralign: 0x4

 i.e. empty sh_flags.  gld seems to mishandle this, since the
 corresponding .initarray entry is bad, as can be seen with runtime
 linker debugging:

 $ LD_DEBUG=init LD_PRELOAD=./libgcc_s.so.1 ls
 [...]
 02032: 1: calling .initarray[0]:0xfed77100: ./libgcc_s.so.1
 02032: 1: calling .initarray[1]:0x2000: ./libgcc_s.so.1
 Segmentation Fault

 If I change the above to

        .section        .init_array,aw,@progbits

 everything works fine with as/gld, but breaks again with gas/gld since
 gas warns about @progbits here.  It turned out that

        .section        .init_array,aw

 is fine with both assemblers, while as doesn't understand @init_array.
 That's what the patch below uses.

 Can you test Linux too?  The change of -e0 looks good, but I'd rather check
 on the actual system.

 This patch has been bootstrapped on i386-pc-solaris2.{8, 9, 10, 11} with
 as/ld, gas/ld and gas/gld, i386-pc-solaris2.11 with as/gld, as well as
 x86_64-unknown-linux-gnu, correctly detecting .init_array etc. support
 on the gld configurations.  It was also included with
 sparc-sun-solaris2.* bootstraps, but even with gas/gld the configure
 test fails.  I've got to investigate that separately.

 I'm not sure about the varasm.c change - it's definitely not a no-op
 (callback will be not set, and the flags will be different).  Certainly
 the current code is inconsistent wrt the priority != DEFAULT_INIT_PRIORITY
 case, not sure why, but you don't make it consistent either because
 you don't change that case to SECTION_NOTYPE either.  I'd be fine
 with it with both calls using SECTION_NOTYPE, but would like to
 know what the callback difference is about.

 HJ, can you shed some light on this?


GNU assembler understands:

.section.init_array*

If Solaris assembler doesn't, I don't know how it will work
with .init_array with priority.


-- 
H.J.

Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

2012-02-16 Thread Rainer Orth 
H.J. Lu hjl.to...@gmail.com writes:

 GNU assembler understands:

 .section.init_array*

 If Solaris assembler doesn't, I don't know how it will work
 with .init_array with priority.

That's not the issue: merging .init_array* sections is handled all right
by gld irrespective of sh_type; there's nothing required from the
assembler here.

My problem is different: consider

$ cat ia-no-sht.s
.section .init_array
$ cat ia-no-sht-f.s
.section .init_array,aw

If I assemble this with gas 2.22, I get the same section header for both
inputs:

gas/ia-no-sht.o:


Section Header[4]:  sh_name: .init_array
sh_addr:  0   sh_flags:   [ SHF_WRITE SHF_ALLOC ]
sh_size:  0   sh_type:[ SHT_INIT_ARRAY ]
sh_offset:0x34sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1   

gas/ia-no-sht-f.o:


Section Header[4]:  sh_name: .init_array
sh_addr:  0   sh_flags:   [ SHF_WRITE SHF_ALLOC ]
sh_size:  0   sh_type:[ SHT_INIT_ARRAY ]
sh_offset:0x34sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1   

With as instead, I get

as/ia-no-sht.o:


Section Header[3]:  sh_name: .init_array
sh_addr:  0   sh_flags:   0
sh_size:  0   sh_type:[ SHT_PROGBITS ]
sh_offset:0x59sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1   

as/ia-no-sht-f.o:


Section Header[3]:  sh_name: .init_array
sh_addr:  0   sh_flags:   [ SHF_WRITE SHF_ALLOC ]
sh_size:  0   sh_type:[ SHT_PROGBITS ]
sh_offset:0x59sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1   


The problem is not the wrong sh_type (SHT_PROGBITS instead of
SHT_INIT_ARRAY): gld handles both input sections alike and doesn't care.
Rather, the 0 sh_flags when no section flags are specified seem to cause
gld to mishandle the resulting objects.

So for gas, my patch makes no difference, but fixes/works around the
problematic as/gld combo.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

2012-02-16 Thread Rainer Orth 
Richard Guenther richard.guent...@gmail.com writes:

 I'm not sure about the varasm.c change - it's definitely not a no-op
 (callback will be not set, and the flags will be different).  Certainly

As I've demonstrated in my response to H.J., the effect with gas is none.

 the current code is inconsistent wrt the priority != DEFAULT_INIT_PRIORITY
 case, not sure why, but you don't make it consistent either because
 you don't change that case to SECTION_NOTYPE either.  I'd be fine

I didn't find a need for that, but agree that the inconsistency is
disturbing.  default_section_type_flags suggests that SECTION_NOTYPE
should be set for .init_array and friends, but it's only used by
get_named_section.

 with it with both calls using SECTION_NOTYPE, but would like to
 know what the callback difference is about.

I don't think the callback is needed, which is effectively a

printf (\t.section\t.init_array);

Looking at it, this is e.g. wrong for Sun as on SPARC, which requires
the section name to be in double quotes.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

2012-02-15 Thread Paolo Bonzini 
On 02/15/2012 06:09 PM, Rainer Orth wrote:
 Paolo Bonzini bonz...@gnu.org writes:
 
 This must be a separate macro in acinclude.m4 that is AC_REQUIREd from
 gcc_AC_INITFINI_ARRAY.
 
 Here's an updated patch that does so.  During testing, I found one
 additional complication, though.  With the Sun as/GNU ld combination on
 Solaris 11/x86, after the bootstrap had completed, all programs linked
 against libgcc_s.so.1 SEGVed with a stacktrace like this:
 
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 1 (LWP 1)]
 0x2000 in ?? ()
 (gdb) where
 #0  0x2000 in ?? ()
 #1  0xfefcd73f in call_array () from /usr/lib/ld.so.1
 #2  0xfefcd8bd in call_init () from /usr/lib/ld.so.1
 #3  0xfefcc8e1 in setup () from /usr/lib/ld.so.1
 #4  0xfefdcfd8 in _setup () from /usr/lib/ld.so.1
 #5  0xfefc0674 in _rt_boot () from /usr/lib/ld.so.1
 #6  0x0804796c in ?? ()
 #7  0x08047ab0 in ?? ()
 Backtrace stopped: previous frame inner to this frame (corrupt stack?)
 
 The problem turned out to be that with
 
   .section.init_array
 
 as generates 
 
 Section Header[5]:  sh_name: .init_array
 sh_addr:  0   sh_flags:   0
 sh_size:  0x4 sh_type:[ SHT_PROGBITS ]
 sh_offset:0x344   sh_entsize: 0
 sh_link:  0   sh_info:0
 sh_addralign: 0x4   
 
 i.e. empty sh_flags.  gld seems to mishandle this, since the
 corresponding .initarray entry is bad, as can be seen with runtime
 linker debugging:
 
 $ LD_DEBUG=init LD_PRELOAD=./libgcc_s.so.1 ls
 [...]
 02032: 1: calling .initarray[0]:0xfed77100: ./libgcc_s.so.1
 02032: 1: calling .initarray[1]:0x2000: ./libgcc_s.so.1
 Segmentation Fault
 
 If I change the above to
 
   .section.init_array,aw,@progbits
 
 everything works fine with as/gld, but breaks again with gas/gld since
 gas warns about @progbits here.  It turned out that 
 
   .section.init_array,aw
 
 is fine with both assemblers, while as doesn't understand @init_array.
 That's what the patch below uses.
 
 Can you test Linux too?  The change of -e0 looks good, but I'd rather check
 on the actual system.
 
 This patch has been bootstrapped on i386-pc-solaris2.{8, 9, 10, 11} with
 as/ld, gas/ld and gas/gld, i386-pc-solaris2.11 with as/gld, as well as
 x86_64-unknown-linux-gnu, correctly detecting .init_array etc. support
 on the gld configurations.  It was also included with
 sparc-sun-solaris2.* bootstraps, but even with gas/gld the configure
 test fails.  I've got to investigate that separately.
 
 Ok for mainline now?
 
 Thanks.
   Rainer
 
 
 2012-01-20  Rainer Orth  r...@cebitec.uni-bielefeld.de
 
   PR target/50166
   * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Require gcc_SUN_LD_VERSION.
   Define _start.
   Remove -e 0 from $gcc_cv_ld invocation.
   Only use __GLIBC_PREREQ if defined.
   Enable on Solaris since Solaris 8 patch.
   (gcc_SUN_LD_VERSION): New macro.
   * configure.ac (ld_ver) *-*-solaris2*: Refer to
   gcc_SUN_LD_VERSION for version number format.
   * configure: Regenerate.
   * varasm.c (get_elf_initfini_array_priority_section): Use
   get_section instead of get_unnamed_section to emit
   .init_array/.fini_array with default priority.

Build parts are okay.  I cannot approve the varasm.c changes.

Paolo

Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

2012-01-30 Thread Rainer Orth 
Jakub Jelinek ja...@redhat.com writes:

 The following patch attempts to perform a separate linker check
 (grepping objdump of a linked binary) and checks so far glibc version
 which is known to support .init_array properly.  Perhaps other
 C libraries could be added there too (does e.g. Solaris support .init_array
 properly, or FreeBSD, other OSes?).

As described in the PR, Solaris ld.so.1 does support
.init_array/.fini_array since an early Solaris 8 patch.

We can (and need to) use the Sun ld version number to check for a
matching ld.so.1 since both are updated in lockstep.  To support that, I
must check ld -V output in the native case even if a different linker is
configured.

The following patch has been bootstrapped without regressions on
i386-pc-solaris2.11 with Sun as/ld, gas/Sun ld, gas/gld, where only the
last combination fully supports .init_array/.fini_array due to the
requirement to merge .[cd]tors.* and .{init,fini}_array.* sections which
only gld does so far.  I've run H.J.'s original test program on Solaris
8 to 11 and it works on Solaris/x86.  The new test doesn't work on
Solaris/SPARC even with gld, still need to investigate why.

Ok for mainline?

Rainer


2012-01-20  Rainer Orth  r...@cebitec.uni-bielefeld.de

PR target/50166
* configure.ac (sun_ld_vers_major, sun_ld_vers_minor): Set on
native *-*-solaris2*.
* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Define _start.
Remove -e 0 from $gcc_cv_ld invocation.
Only use __GLIBC_PREREQ if defined.
Enable on Solaris since Solaris 8 patch.
* configure: Regenerate.

# HG changeset patch
# Parent 94f7fcd05ab2cbde19449f1a0fe7151dc01a8208
Enable initfini array support on Solaris

diff --git a/gcc/acinclude.m4 b/gcc/acinclude.m4
--- a/gcc/acinclude.m4
+++ b/gcc/acinclude.m4
@@ -1,4 +1,5 @@
-dnl Copyright (C) 2005, 2006, 2007, 2008, 2011 Free Software Foundation, Inc.
+dnl Copyright (C) 2005, 2006, 2007, 2008, 2011, 2012
+dnl Free Software Foundation, Inc.
 dnl
 dnl This file is part of GCC.
 dnl
@@ -427,9 +428,11 @@ int (*fp) (void) __attribute__ ((section
 .balign 4
 .byte 'H', 'H', 'H', 'H'
 .text
+.globl _start
+_start:
 EOF
 	  if $gcc_cv_as -o conftest.o conftest.s  /dev/null 21 \
-	  $gcc_cv_ld -e 0 -o conftest conftest.o  /dev/null 21 \
+	  $gcc_cv_ld -o conftest conftest.o  /dev/null 21 \
 	  $gcc_cv_objdump -s -j .init_array conftest \
 		| grep   /dev/null 21 \
 	  $gcc_cv_objdump -s -j .fini_array conftest \
@@ -442,14 +445,38 @@ changequote([,])dnl
 	fi
 	AC_PREPROC_IFELSE([AC_LANG_SOURCE([
 #ifndef __ELF__
-#error Not an ELF OS
+# error Not an ELF OS
 #endif
 #include stdlib.h
-#if defined __GLIBC_PREREQ  __GLIBC_PREREQ (2, 4)
+#if defined __GLIBC_PREREQ
+# if __GLIBC_PREREQ (2, 4)
+# else
+#  error GLIBC 2.4 required
+# endif
 #else
-#error The C library not known to support .init_array/.fini_array
+# if defined __sun__  defined __svr4__
+   /* Solaris ld.so.1 supports .init_array/.fini_array since Solaris 8.  */
+# else
+#  error The C library not known to support .init_array/.fini_array
+# endif
 #endif
-])],, [gcc_cv_initfini_array=no]);;
+])],[
+case ${target} in
+  *-*-solaris2.8*)
+	# .init_array/.fini_array support was introduced in Solaris 8
+	# patches 109147-08 (sparc) and 109148-08 (x86).  Since ld.so.1 and
+	# ld are guaranteed to be updated in lockstep, we can check ld -V
+	# instead.  Unfortunately, proper ld version numbers were only
+	# introduced in rev. -14, so we check for that.
+  	if test $sun_ld_vers_minor -lt 272; then
+	  gcc_cv_initfini_array=no
+	fi
+  ;;
+  *-*-solaris2.9* | *-*-solaris2.1[[0-9]]*)
+# .init_array/.fini_array support is present since Solaris 9 FCS.
+;;
+esac
+], [gcc_cv_initfini_array=no]);;
 esac
   else
 AC_MSG_CHECKING(cross compile... guessing)
diff --git a/gcc/configure.ac b/gcc/configure.ac
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -2270,6 +2270,25 @@ if test x$enable_gnu_indirect_function =
 fi
 
 changequote(,)dnl
+if test x${build} = x${target}  test x${build} = x${host}; then
+  case ${target} in
+*-*-solaris2*)
+  # ld.so.1 and ld are guaranteed to be updated in lockstep, so check
+  # ld version number for use in ld.so.1 feature checks even if a
+  # different linker is configured.
+  #
+  # See below for the version number formats.
+  sun_ld_ver=`/usr/ccs/bin/ld -V 21`
+  if echo $sun_ld_ver | grep 'Solaris Link Editors'  /dev/null; then
+	sun_ld_vers=`echo $sun_ld_ver | sed -n \
+	  -e 's,^.*: 5\.[0-9][0-9]*-\([0-9]\.[0-9][0-9]*\).*$,\1,p'`
+	sun_ld_vers_major=`expr $sun_ld_vers : '\([0-9]*\)'`
+	sun_ld_vers_minor=`expr $sun_ld_vers : '[0-9]*\.\([0-9]*\)'`
+  fi
+  ;;
+  esac
+fi
+
 if test $in_tree_ld != yes ; then
   ld_ver=`$gcc_cv_ld --version 2/dev/null | sed 1q`
   if echo $ld_ver | grep GNU  /dev/null; then
@@ -2305,6 +2324,9 @@ if test $in_tree_ld != yes ; then
 	#
 	# ld: Software

Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

2012-01-30 Thread Paolo Bonzini 

Jakub Jelinek ja...@redhat.com writes:


The following patch attempts to perform a separate linker check
(grepping objdump of a linked binary) and checks so far glibc version
which is known to support .init_array properly.  Perhaps other
C libraries could be added there too (does e.g. Solaris support .init_array
properly, or FreeBSD, other OSes?).

As described in the PR, Solaris ld.so.1 does support
.init_array/.fini_array since an early Solaris 8 patch.

We can (and need to) use the Sun ld version number to check for a
matching ld.so.1 since both are updated in lockstep.  To support that, I
must check ld -V output in the native case even if a different linker is
configured.

The following patch has been bootstrapped without regressions on
i386-pc-solaris2.11 with Sun as/ld, gas/Sun ld, gas/gld, where only the
last combination fully supports .init_array/.fini_array due to the
requirement to merge .[cd]tors.* and .{init,fini}_array.* sections which
only gld does so far.  I've run H.J.'s original test program on Solaris
8 to 11 and it works on Solaris/x86.  The new test doesn't work on
Solaris/SPARC even with gld, still need to investigate why.

Ok for mainline?

Rainer


2012-01-20  Rainer Orth  r...@cebitec.uni-bielefeld.de

PR target/50166
* configure.ac (sun_ld_vers_major, sun_ld_vers_minor): Set on
native *-*-solaris2*.
* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Define _start.
Remove -e 0 from $gcc_cv_ld invocation.
Only use __GLIBC_PREREQ if defined.
Enable on Solaris since Solaris 8 patch.
* configure: Regenerate.



sol2-initfini-array.patch

# HG changeset patch
# Parent 94f7fcd05ab2cbde19449f1a0fe7151dc01a8208
Enable initfini array support on Solaris

diff --git a/gcc/acinclude.m4 b/gcc/acinclude.m4
--- a/gcc/acinclude.m4
+++ b/gcc/acinclude.m4
@@ -1,4 +1,5 @@
-dnl Copyright (C) 2005, 2006, 2007, 2008, 2011 Free Software Foundation, Inc.
+dnl Copyright (C) 2005, 2006, 2007, 2008, 2011, 2012
+dnl Free Software Foundation, Inc.
 dnl
 dnl This file is part of GCC.
 dnl
@@ -427,9 +428,11 @@ int (*fp) (void) __attribute__ ((section
 .balign 4
 .byte 'H', 'H', 'H', 'H'
 .text
+.globl _start
+_start:
 EOF
  if $gcc_cv_as -o conftest.o conftest.s  /dev/null 21 \
- $gcc_cv_ld -e 0 -o conftest conftest.o  /dev/null 21 \
+ $gcc_cv_ld -o conftest conftest.o  /dev/null 21 \
  $gcc_cv_objdump -s -j .init_array conftest \
| grep   /dev/null 21 \
  $gcc_cv_objdump -s -j .fini_array conftest \
@@ -442,14 +445,38 @@ changequote([,])dnl
fi
AC_PREPROC_IFELSE([AC_LANG_SOURCE([
 #ifndef __ELF__
-#error Not an ELF OS
+# error Not an ELF OS
 #endif
 #include stdlib.h
-#if defined __GLIBC_PREREQ  __GLIBC_PREREQ (2, 4)
+#if defined __GLIBC_PREREQ
+# if __GLIBC_PREREQ (2, 4)
+# else
+#  error GLIBC 2.4 required
+# endif
 #else
-#error The C library not known to support .init_array/.fini_array
+# if defined __sun__  defined __svr4__
+   /* Solaris ld.so.1 supports .init_array/.fini_array since Solaris 8.  */
+# else
+#  error The C library not known to support .init_array/.fini_array
+# endif
 #endif
-])],, [gcc_cv_initfini_array=no]);;
+])],[
+case ${target} in
+  *-*-solaris2.8*)
+   # .init_array/.fini_array support was introduced in Solaris 8
+   # patches 109147-08 (sparc) and 109148-08 (x86).  Since ld.so.1 and
+   # ld are guaranteed to be updated in lockstep, we can check ld -V
+   # instead.  Unfortunately, proper ld version numbers were only
+   # introduced in rev. -14, so we check for that.
+   if test $sun_ld_vers_minor -lt 272; then
+ gcc_cv_initfini_array=no
+   fi
+  ;;
+  *-*-solaris2.9* | *-*-solaris2.1[[0-9]]*)
+# .init_array/.fini_array support is present since Solaris 9 FCS.
+;;
+esac
+], [gcc_cv_initfini_array=no]);;
 esac
   else
 AC_MSG_CHECKING(cross compile... guessing)
diff --git a/gcc/configure.ac b/gcc/configure.ac
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -2270,6 +2270,25 @@ if test x$enable_gnu_indirect_function =
 fi

 changequote(,)dnl
+if test x${build} = x${target}  test x${build} = x${host}; then
+  case ${target} in
+*-*-solaris2*)
+  # ld.so.1 and ld are guaranteed to be updated in lockstep, so check
+  # ld version number for use in ld.so.1 feature checks even if a
+  # different linker is configured.
+  #
+  # See below for the version number formats.
+  sun_ld_ver=`/usr/ccs/bin/ld -V 21`
+  if echo $sun_ld_ver | grep 'Solaris Link Editors'  /dev/null; then
+   sun_ld_vers=`echo $sun_ld_ver | sed -n \
+ -e 's,^.*: 5\.[0-9][0-9]*-\([0-9]\.[0-9][0-9]*\).*$,\1,p'`
+   sun_ld_vers_major=`expr $sun_ld_vers : '\([0-9]*\)'`
+   sun_ld_vers_minor=`expr $sun_ld_vers : '[0-9]*\.\([0-9]*\)'`
+  fi
+  ;;
+  esac
+fi


This must be a separate macro in acinclude.m4 that is

Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

2012-01-30 Thread Rainer Orth 
Paolo Bonzini bonz...@gnu.org writes:

  changequote(,)dnl
 +if test x${build} = x${target}  test x${build} = x${host}; then
 +  case ${target} in
 +*-*-solaris2*)
 +  # ld.so.1 and ld are guaranteed to be updated in lockstep, so check
 +  # ld version number for use in ld.so.1 feature checks even if a
 +  # different linker is configured.
 +  #
 +  # See below for the version number formats.
 +  sun_ld_ver=`/usr/ccs/bin/ld -V 21`
 +  if echo $sun_ld_ver | grep 'Solaris Link Editors'  /dev/null; then
 +sun_ld_vers=`echo $sun_ld_ver | sed -n \
 +  -e 's,^.*: 5\.[0-9][0-9]*-\([0-9]\.[0-9][0-9]*\).*$,\1,p'`
 +sun_ld_vers_major=`expr $sun_ld_vers : '\([0-9]*\)'`
 +sun_ld_vers_minor=`expr $sun_ld_vers : '[0-9]*\.\([0-9]*\)'`
 +  fi
 +  ;;
 +  esac
 +fi

 This must be a separate macro in acinclude.m4 that is AC_REQUIREd from
 gcc_AC_INITFINI_ARRAY.

Ok, will do.

 Can you test Linux too?  The change of -e0 looks good, but I'd rather check
 on the actual system.

I can test on x86_64-unknown-linux-gnu, just not on my laptop at home.
Actually, Jakub suggested the change in the PR since Sun ld complains
about -e 0.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

2012-01-30 Thread Paolo Bonzini 

On 01/30/2012 06:00 PM, Rainer Orth wrote:

  Can you test Linux too?  The change of -e0 looks good, but I'd rather check
  on the actual system.

I can test on x86_64-unknown-linux-gnu, just not on my laptop at home.


Note that you only need to test ./configure, not bootstrap/regtest.


Actually, Jakub suggested the change in the PR since Sun ld complains
about -e 0.


Good to know. :)

Paolo

Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

2012-01-19 Thread Paolo Bonzini 

On 01/19/2012 12:24 AM, Jakub Jelinek wrote:

if test x${build} = x${target}  test x${build} = x${host}; then


This test is no longer necessary, is it? ia64 does its own cross-compile 
detection via AC_RUN_IFELSE, and other hosts are cross-compile safe. 
The patch is okay if you remove it.


H.J., can ia64 fall back to the common test when cross compiling?  Or 
perhaps even always?


Paolo

Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

2012-01-19 Thread Jakub Jelinek 
On Thu, Jan 19, 2012 at 09:54:43AM +0100, Paolo Bonzini wrote:
 On 01/19/2012 12:24 AM, Jakub Jelinek wrote:
 if test x${build} = x${target}  test x${build} = x${host}; then
 
 This test is no longer necessary, is it? ia64 does its own
 cross-compile detection via AC_RUN_IFELSE, and other hosts are
 cross-compile safe. The patch is okay if you remove it.

While the linker test is done using the target linker (it uses default
linker flags btw, so in case a linker would be buggy for one target and not
for a different target also supported by the same linker, it would be
a problem, but let's assume that the linker is either buggy or not for
all targets it supports), AC_PREPROC_IFELSE is done using the host compiler.
For cross-compiling we would need to check the target libc headers.
For glibc we could certainly do something similar to the
case $target in
   *-*-linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu)
  [# glibc 2.4 and later provides __stack_chk_fail and
  # either __stack_chk_guard, or TLS access to stack guard canary.
  if test -f $target_header_dir/features.h \
  $EGREP '^[  ]*#[]*define[   ]+__GNU_LIBRARY__[  
]+([1-9][0-9]|[6-9])' \
$target_header_dir/features.h  /dev/null; then
if $EGREP '^[   ]*#[]*define[   ]+__GLIBC__[
]+([1-9][0-9]|[3-9])' \
   $target_header_dir/features.h  /dev/null; then
  gcc_cv_libc_provides_ssp=yes
elif $EGREP '^[ ]*#[]*define[   ]+__GLIBC__[]+2' \
 $target_header_dir/features.h  /dev/null \
  $EGREP '^[  ]*#[]*define[   ]+__GLIBC_MINOR__[  
]+([1-9][0-9]|[4-9])' \
 $target_header_dir/features.h  /dev/null; then
  gcc_cv_libc_provides_ssp=yes
fi
  fi]
test configure already does (and glibc only supports ELF targets, so
the ELF check could be avoided).

 H.J., can ia64 fall back to the common test when cross compiling?
 Or perhaps even always?

I've kept ia64 as is because that is what we did for ia64 configure already
in 4.6 and earlier.  As ia64 was using .init_array etc. far before the
linker merging of .ctors and .init_array has been fixed, probably it just
switched over to .init_array completely many years ago or something.

Jakub

[PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

2012-01-18 Thread Jakub Jelinek 
Hi!

As discussed in the PR, compiling the initfini testcase with the
host compiler and running it is problematic for bootstrap, as
in stage1 we use the host compiler which might use one version of as/ld,
but stage2 is using stage1 compiler as host compiler and might use
a different as/ld.  If one of the linkers does support merging of
.init_array and .ctors properly and the other does not, we end up
with comparison failures e.g. because of go1 C++ sources.

The following patch attempts to perform a separate linker check
(grepping objdump of a linked binary) and checks so far glibc version
which is known to support .init_array properly.  Perhaps other
C libraries could be added there too (does e.g. Solaris support .init_array
properly, or FreeBSD, other OSes?).

Bootstrapped/regtested on x86_64-linux and i686-linux both with a linker
that does it right and a buggy one.

2012-01-18  Jakub Jelinek  ja...@redhat.com

PR bootstrap/50237
* config/initfini-array.h: Guard content of the header
with #ifdef HAVE_INITFINI_ARRAY.
* configure.ac: Move gcc_AC_INITFINI_ARRAY much later into the file.
Add initfini-array.h to tm_file here.
* acinclude.m4 (gcc_AC_INITFINI_ARRAY): For non-ia64 do a linker
test.
* config.gcc: Don't add initfini-array.h to tm_file here.
* configure: Regenerated.

--- gcc/config/initfini-array.h.jj  2011-08-22 08:17:06.0 +0200
+++ gcc/config/initfini-array.h 2012-01-17 16:28:39.219571262 +0100
@@ -19,6 +19,8 @@
along with GCC; see the file COPYING3.  If not see
http://www.gnu.org/licenses/.  */
 
+#ifdef HAVE_INITFINI_ARRAY
+
 #define USE_INITFINI_ARRAY
 
 #undef INIT_SECTION_ASM_OP
@@ -35,3 +37,5 @@
 #define TARGET_ASM_CONSTRUCTOR default_elf_init_array_asm_out_constructor
 #undef TARGET_ASM_DESTRUCTOR
 #define TARGET_ASM_DESTRUCTOR default_elf_fini_array_asm_out_destructor
+
+#endif
--- gcc/configure.ac.jj 2012-01-13 21:47:35.0 +0100
+++ gcc/configure.ac2012-01-17 16:28:00.461795315 +0100
@@ -1197,8 +1197,6 @@ fi
 CFLAGS=$saved_CFLAGS
 CXXFLAGS=$saved_CXXFLAGS
 
-gcc_AC_INITFINI_ARRAY
-
 # mkdir takes a single argument on some systems. 
 gcc_AC_FUNC_MKDIR_TAKES_ONE_ARG
 
@@ -1271,6 +1269,11 @@ if test x$tmake_file = x
 then tmake_file=$cpu_type/t-$cpu_type
 fi
 
+# Support --enable-initfini-array.
+if test x$enable_initfini_array != xno; then
+  tm_file=${tm_file} initfini-array.h
+fi
+
 if test x$dwarf2 = xyes
 then tm_file=$tm_file tm-dwarf2.h
 fi
@@ -2422,6 +2425,8 @@ if test x$gcc_cv_ld_ro_rw_mix = xread-wr
 fi
 AC_MSG_RESULT($gcc_cv_ld_ro_rw_mix)
 
+gcc_AC_INITFINI_ARRAY
+
 # Check if we have .[us]leb128, and support symbol arithmetic with it.
 gcc_GAS_CHECK_FEATURE([.sleb128 and .uleb128], gcc_cv_as_leb128,
   [elf,2,11,0],,
--- gcc/acinclude.m4.jj 2011-08-26 18:41:44.0 +0200
+++ gcc/acinclude.m42012-01-18 20:41:51.448002554 +0100
@@ -376,119 +376,85 @@ AC_DEFUN([gcc_AC_INITFINI_ARRAY],
 AC_CACHE_CHECK(for .preinit_array/.init_array/.fini_array support,
 gcc_cv_initfini_array, [dnl
   if test x${build} = x${target}  test x${build} = x${host}; then
-AC_RUN_IFELSE([AC_LANG_SOURCE([
+case ${target} in
+  ia64-*)
+   AC_RUN_IFELSE([AC_LANG_SOURCE([
 #ifndef __ELF__
 #error Not an ELF OS
 #endif
-#ifdef __ia64__
 /* We turn on .preinit_array/.init_array/.fini_array support for ia64
if it can be used.  */
 static int x = -1;
 int main (void) { return x; }
 int foo (void) { x = 0; }
 int (*fp) (void) __attribute__ ((section (.init_array))) = foo;
-#else
-extern void abort ();
-static int count;
-
-static void
-init1005 ()
-{
-  if (count != 0)
-abort ();
-  count = 1005;
-}
-void (*const init_array1005[]) ()
-  __attribute__ ((section (.init_array.01005), aligned (sizeof (void *
-  = { init1005 };
-static void
-fini1005 ()
-{
-  if (count != 1005)
-abort ();
-}
-void (*const fini_array1005[]) ()
-  __attribute__ ((section (.fini_array.01005), aligned (sizeof (void *
-  = { fini1005 };
-
-static void
-ctor1007 ()
-{
-  if (count != 1005)
-abort ();
-  count = 1007;
-}
-void (*const ctors1007[]) ()
-  __attribute__ ((section (.ctors.64528), aligned (sizeof (void *
-  = { ctor1007 };
-static void
-dtor1007 ()
-{
-  if (count != 1007)
-abort ();
-  count = 1005;
-}
-void (*const dtors1007[]) ()
-  __attribute__ ((section (.dtors.64528), aligned (sizeof (void *
-  = { dtor1007 };
-
-static void
-init65530 ()
-{
-  if (count != 1007)
-abort ();
-  count = 65530;
-}
-void (*const init_array65530[]) ()
-  __attribute__ ((section (.init_array.65530), aligned (sizeof (void *
-  = { init65530 };
-static void
-fini65530 ()
-{
-  if (count != 65530)
-abort ();
-  count = 1007;
-}
-void (*const fini_array65530[]) ()
-  __attribute__ ((section (.fini_array.65530), aligned (sizeof (void *
-  = { fini65530 };
-
-static void
-ctor65535 ()
-{
-  if (count != 65530)
-abort ();
-  count = 65535;
-}
-void (*const