Bug 50237 - [4.7 regression] bootstrap comparison failure for libcpp/lex.o
Summary: [4.7 regression] bootstrap comparison failure for libcpp/lex.o
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.7.0
: P1 critical
Target Milestone: 4.7.0
Assignee: Not yet assigned to anyone
URL: http://gcc.gnu.org/ml/gcc-patches/201...
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-30 13:19 UTC by Eric Botcazou
Modified: 2012-02-22 22:26 UTC (History)
7 users (show)

See Also:
Host: x86_64-suse-linux, *-*-solaris2*
Target: x86_64-suse-linux, *-*-solaris2*
Build: x86_64-suse-linux, *-*-solaris2*
Known to work:
Known to fail:
Last reconfirmed: 2011-10-04 00:00:00


Attachments
gcc47-pr50237.patch (914 bytes, patch)
2011-11-28 15:10 UTC, Jakub Jelinek
Details | Diff
gcc47-pr50237.patch (3.44 KB, patch)
2012-01-17 16:00 UTC, Jakub Jelinek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Botcazou 2011-08-30 13:19:39 UTC
I have had a bootstrap comparison failure for days on x86-64/Linux:

libcpp/lex.o differs

It turns out that stage3 has

  6 .init_array   00000008  0000000000000000  0000000000000000  00003d20  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA

but stage2 has

  6 .ctors        00000008  0000000000000000  0000000000000000  00003d20  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA

That isn't surprising because HAVE_INITFINI_ARRAY isn't uniform:

eric@hermes:~/build/gcc/native> grep HAVE_INITFINI_ARRAY stage1-gcc/auto-host.h 
/* #undef HAVE_INITFINI_ARRAY */
eric@hermes:~/build/gcc/native> grep HAVE_INITFINI_ARRAY prev-gcc/auto-host.h
#define HAVE_INITFINI_ARRAY 1

i.e. despite http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00659.html the check is still applied to the host compiler, not to the target.  The base compiler is the system compiler on OpenSuSE 11.0 and the check doesn't pass for it:

eric@hermes:~/build/gcc/native> gcc -o t t.c
eric@hermes:~/build/gcc/native> ./t
Aborted

The compiler is configured with

eric@hermes:~/build/gcc/native> gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: x86_64-suse-linux
Configured with: /home/eric/svn/gcc/configure x86_64-suse-linux --prefix=/home/eric/install/gcc --with-as=/home/eric/build/binutils/native/gas/as-new --with-ld=/home/eric/build/binutils/native/ld/ld-new --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-checking=yes,rtl --enable-__cxa_atexit --disable-nls --disable-libmudflap
Thread model: posix
gcc version 4.7.0 20110830 (experimental) [trunk revision 178287] (GCC)


A workaround would be to get rid of the __attribute__((constructor)) in lex.c but someone should sit down and write a correct HAVE_INITFINI_ARRAY check.
Comment 1 H.J. Lu 2011-08-30 13:40:54 UTC
HAVE_INITFINI_ARRAY is supposed to check the binutils/glibc feature,
independent of compiler.  Which GCC does OpenSuSE 11.0 have?
Comment 2 Eric Botcazou 2011-08-30 13:50:28 UTC
> HAVE_INITFINI_ARRAY is supposed to check the binutils/glibc feature,
> independent of compiler.

AFAICS it doesn't, it compiles everything with the host compiler, which will use in particular the old binutils.  See by contrast various tests in configure.ac that really check the features of the new binutils.

> Which GCC does OpenSuSE 11.0 have?

Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.3 --enable-version-specific-runtime-libs --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE Linux)
Comment 3 H.J. Lu 2011-08-30 13:57:46 UTC
(In reply to comment #2)
> > HAVE_INITFINI_ARRAY is supposed to check the binutils/glibc feature,
> > independent of compiler.
> 
> AFAICS it doesn't, it compiles everything with the host compiler, which will
> use in particular the old binutils.  See by contrast various tests in
> configure.ac that really check the features of the new binutils.
> 

How is the different binutils in stage 1/2/3? Can you use
the same binutils in stage 1/2/3?
Comment 4 Richard Biener 2011-08-30 14:09:08 UTC
Only stage2/3 binutils need to be the same and those are relevant for
feature tests.
Comment 5 H.J. Lu 2011-08-30 14:23:05 UTC
(In reply to comment #4)
> Only stage2/3 binutils need to be the same and those are relevant for
> feature tests.

How does stage 2 binutils fail the test?
Comment 6 Eric Botcazou 2011-08-30 15:00:54 UTC
> How does stage 2 binutils fail the test?

It doesn't.  Let me explain:

  - during stage1, the check is made with the host compiler, i.e. the base compiler, so the old binutils are used and the check fails, that's why we have

/* #undef HAVE_INITFINI_ARRAY */

in stage1-gcc/auto-host.h.  This means that the stage1 compiler doesn't have the support.  Since this compiler is used to compile stage2 libcpp/lex.o, the file gets the .ctors section.

  - during stage2, the check is made with the host cmpiler, i.e. the stage 1 compiler, so the new binutils (--with-as=, --with-ld) are used and the check succeeds, that's why we have

#define HAVE_INITFINI_ARRAY 1

in stage2-gcc/auto-host.h.  This means that the stage2 compiler has the support.
Since this compiler is used to compile stage3 libcpp/lex.o, the file gets the
.init_array section.


The fix is to turn the check into a target check, i.e. test the target binutils.
See configure.ac:1884 and below.
Comment 7 joseph@codesourcery.com 2011-08-30 15:40:49 UTC
On Tue, 30 Aug 2011, ebotcazou at gcc dot gnu.org wrote:

> The fix is to turn the check into a target check, i.e. test the target
> binutils.
> See configure.ac:1884 and below.

And a proper target check should not be testing execution of the generated 
code to work properly with cross compilation.  The following are 
unconditionally safe:

* Testing the target triplet.  In particular, use ACX_ELF_TARGET_IFELSE 
(config/elf.m4) to eliminate non-ELF targets.

* Testing uses of the assembler and linker, and using target objdump (when 
using GNU binutils) to examine the result, as long as the linker uses do 
not require any target libraries to be present.

* Examining target headers (see the code checking for glibc versions in 
$target_header_dir/features.h).

The first two should be able to tell if the assembler and linker have all 
the required features.  init_array and fini_array are standard ELF 
features so I think the default should be to assume they will work on the 
target (if ELF) unless a reason arises to blacklist particular targets.
Comment 8 H.J. Lu 2011-08-30 15:55:51 UTC
The main issue is mixing input .ctors sections with .init_array sections
to generate the single output .init_array section.  Not all linkers support
it even if they support .init_array section.  How should we properly
test this?
Comment 9 H.J. Lu 2011-08-30 15:56:45 UTC
In the meantime, you can use --enable-initfini-array/--disable-initfini-array
to work around this.
Comment 10 joseph@codesourcery.com 2011-08-30 16:39:39 UTC
On Tue, 30 Aug 2011, hjl.tools at gmail dot com wrote:

> The main issue is mixing input .ctors sections with .init_array sections
> to generate the single output .init_array section.  Not all linkers support
> it even if they support .init_array section.  How should we properly
> test this?

Is it not possible to link (with -r, maybe) objects and examine the output 
with target objdump to see if .ctors sections are still present?
Comment 11 H.J. Lu 2011-08-31 04:21:53 UTC
(In reply to comment #10)
> On Tue, 30 Aug 2011, hjl.tools at gmail dot com wrote:
> 
> > The main issue is mixing input .ctors sections with .init_array sections
> > to generate the single output .init_array section.  Not all linkers support
> > it even if they support .init_array section.  How should we properly
> > test this?
> 
> Is it not possible to link (with -r, maybe) objects and examine the output 
> with target objdump to see if .ctors sections are still present?

"ld -r" won't/shouldn't combine different sections.  We
can use ld to generate executables.  How can we check if
input .ctors.* and .init_array.* sections are placed
in the right order?
Comment 12 joseph@codesourcery.com 2011-08-31 15:27:44 UTC
On Wed, 31 Aug 2011, hjl.tools at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
> 
> --- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-31 04:21:53 UTC ---
> (In reply to comment #10)
> > On Tue, 30 Aug 2011, hjl.tools at gmail dot com wrote:
> > 
> > > The main issue is mixing input .ctors sections with .init_array sections
> > > to generate the single output .init_array section.  Not all linkers support
> > > it even if they support .init_array section.  How should we properly
> > > test this?
> > 
> > Is it not possible to link (with -r, maybe) objects and examine the output 
> > with target objdump to see if .ctors sections are still present?
> 
> "ld -r" won't/shouldn't combine different sections.  We
> can use ld to generate executables.  How can we check if
> input .ctors.* and .init_array.* sections are placed
> in the right order?

Arrange for the contents to have appropriate text values you can check for 
with grep (or if you wish a custom C program to run on the build system to 
examine ELF structures - only ELF needs to be considered for this, after 
all, and I think at this point you may even be able to rely on having 
libiberty already built for the build system, complete with the 
simple-object-elf code).
Comment 13 H.J. Lu 2011-08-31 15:44:02 UTC
(In reply to comment #12)
> 
> Arrange for the contents to have appropriate text values you can check for 
> with grep (or if you wish a custom C program to run on the build system to 
> examine ELF structures - only ELF needs to be considered for this, after 
> all, and I think at this point you may even be able to rely on having 
> libiberty already built for the build system, complete with the 
> simple-object-elf code).

.init_array section is an array of pointers. How do you grep it?
Comment 14 joseph@codesourcery.com 2011-08-31 15:46:46 UTC
On Wed, 31 Aug 2011, hjl.tools at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
> 
> --- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-31 15:44:02 UTC ---
> (In reply to comment #12)
> > 
> > Arrange for the contents to have appropriate text values you can check for 
> > with grep (or if you wish a custom C program to run on the build system to 
> > examine ELF structures - only ELF needs to be considered for this, after 
> > all, and I think at this point you may even be able to rely on having 
> > libiberty already built for the build system, complete with the 
> > simple-object-elf code).
> 
> .init_array section is an array of pointers. How do you grep it?

You arrange for the pointers to be assigned values whose bytes happen to 
correspond to text (endian-independent text, ideally).  Just like using 
grep to determine target endianness or floating point format.
Comment 15 H.J. Lu 2011-09-02 18:09:41 UTC
(In reply to comment #14)
> > 
> > .init_array section is an array of pointers. How do you grep it?
> 
> You arrange for the pointers to be assigned values whose bytes happen to 
> correspond to text (endian-independent text, ideally).  Just like using 
> grep to determine target endianness or floating point format.

I couldn't find an uniform way to assign a fixed address to symbol
in a section which works for all ELF targets.
Comment 16 Eric Botcazou 2011-09-03 09:31:22 UTC
The --disable-initfini-array workaround works fine so downgrading slightly.
Comment 17 H.J. Lu 2011-09-03 17:16:17 UTC
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00223.html
Comment 18 H.J. Lu 2011-09-10 14:45:40 UTC
The updated patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00668.html
Comment 19 Rainer Orth 2011-10-04 13:54:59 UTC
I observe exactly the same problem on Solaris 11/x86, especially with Go:

gcc/go/unsafe.o differs
gcc/go/lex.o differs
gcc/go/runtime.o differs
gcc/go/expressions.o differs
gcc/go/dataflow.o differs
gcc/go/ast-dump.o differs
gcc/go/go-gcc.o differs
gcc/go/import.o differs
gcc/go/go.o differs
gcc/go/export.o differs
gcc/go/go-optimize.o differs
gcc/go/go-dump.o differs
gcc/go/import-archive.o differs
gcc/go/gogo.o differs
gcc/go/statements.o differs
gcc/go/gogo-tree.o differs
gcc/go/types.o differs
gcc/go/parse.o differs

The bootstrap compiler is gcc 4.4.2 configured with gas 2.19 and Sun ld, while
I'm configuring with gas and gld 2.21.90 which have full .init_array/.fini_array
support as required by H.J.'s check.

Initially, I tried make bootstrap4, assuming that the comparison of stage2 and
stage3 would be skipped in favour of the stage3/stage4 comparison (which works
ok), but unfortunately this is not the case.

  Rainer
Comment 20 ro@CeBiTec.Uni-Bielefeld.DE 2011-11-22 17:21:38 UTC
HJ,

with binutils 2.22 now released, could you please work to get this
fixed?  IMO binutils releases need to work for bootstrapping gcc out of
the box without any workarounds on the part of the installer.

Thanks.
        Rainer
Comment 21 H.J. Lu 2011-11-22 17:52:52 UTC
(In reply to comment #20)
> HJ,
> 
> with binutils 2.22 now released, could you please work to get this
> fixed?  IMO binutils releases need to work for bootstrapping gcc out of
> the box without any workarounds on the part of the installer.
> 

There is not much I can do when there are 2 binutils used.
Comment 22 ro@CeBiTec.Uni-Bielefeld.DE 2011-11-22 17:55:15 UTC
But this is the common case: you cannot expect or require the bootstrap
compiler to use the same linker as you configure with.  This is a
bootstrap failure which is going to get us much noise if not fixed.

	Rainer
Comment 23 H.J. Lu 2011-11-22 18:03:09 UTC
(In reply to comment #22)
> But this is the common case: you cannot expect or require the bootstrap
> compiler to use the same linker as you configure with.  This is a
> bootstrap failure which is going to get us much noise if not fixed.
> 

Have you tried the patch in comment 18?
Comment 24 ro@CeBiTec.Uni-Bielefeld.DE 2011-11-23 15:27:22 UTC
> --- Comment #23 from H.J. Lu <hjl.tools at gmail dot com> 2011-11-22 18:03:09 UTC ---
> (In reply to comment #22)
>> But this is the common case: you cannot expect or require the bootstrap
>> compiler to use the same linker as you configure with.  This is a
>> bootstrap failure which is going to get us much noise if not fixed.
>> 
>
> Have you tried the patch in comment 18?

Not yet, but I'm pretty sure it's wrong: In stage 1, the bootstrap
compiler needn't be gcc, thus may not understand -B, so the result would
be wrong even if you configure with gld 2.22.  I don't understand why
you go through so many contortions, full of unwarranted assumptions,
when a simple check for gld >= 2.22 (or 2.21.9x if absolutely necessary)
would do.  If other linkers gain the same support, the test can be
augmented accordingly.  I know this is ugly and real feature checks are
the preferred way, but they are notoriously hard to get right portably,
so many of them already go this route.

	Rainer
Comment 25 H.J. Lu 2011-11-23 16:42:43 UTC
(In reply to comment #24)
> > --- Comment #23 from H.J. Lu <hjl.tools at gmail dot com> 2011-11-22 18:03:09 UTC ---
> > (In reply to comment #22)
> >> But this is the common case: you cannot expect or require the bootstrap
> >> compiler to use the same linker as you configure with.  This is a
> >> bootstrap failure which is going to get us much noise if not fixed.
> >> 
> >
> > Have you tried the patch in comment 18?
> 
> Not yet, but I'm pretty sure it's wrong: In stage 1, the bootstrap
> compiler needn't be gcc, thus may not understand -B, so the result would
> be wrong even if you configure with gld 2.22.  I don't understand why
> you go through so many contortions, full of unwarranted assumptions,
> when a simple check for gld >= 2.22 (or 2.21.9x if absolutely necessary)
> would do.  If other linkers gain the same support, the test can be
> augmented accordingly.  I know this is ugly and real feature checks are
> the preferred way, but they are notoriously hard to get right portably,
> so many of them already go this route.
> 

Checking linker version is inaccurate since this feature requires
support in assembler, linker as well as libc. We can disable it by'
default when 2 linkers are used.
Comment 26 ro@CeBiTec.Uni-Bielefeld.DE 2011-11-23 16:53:16 UTC
> Checking linker version is inaccurate since this feature requires
> support in assembler, linker as well as libc. We can disable it by'
> default when 2 linkers are used.

Then why not check those separately and combine the result.  It's
certainly more reliable than the current guesswork.

	Rainer
Comment 27 H.J. Lu 2011-11-23 17:15:58 UTC
(In reply to comment #26)
> > Checking linker version is inaccurate since this feature requires
> > support in assembler, linker as well as libc. We can disable it by'
> > default when 2 linkers are used.
> 
> Then why not check those separately and combine the result.  It's
> certainly more reliable than the current guesswork.
> 

This test uses the run-time test to check if .ctors and .init_array
input sections can be mixed.  Separate tests don't make much sense.
Comment 28 ro@CeBiTec.Uni-Bielefeld.DE 2011-11-24 17:44:03 UTC
> This test uses the run-time test to check if .ctors and .init_array
> input sections can be mixed.  Separate tests don't make much sense.

Would you care to elaborate why checking the versions resp. features of
the prerequisite components is not enough?

Btw., what libc is required?  I've successfully built and tested with
--enable-init-fini-array on Solaris 11 (with no glibc in sight),
provided I run a make bootstrap4 and ignore the comparison failure in
stage3.

	Rainer
Comment 29 Jakub Jelinek 2011-11-28 15:10:00 UTC
Created attachment 25937 [details]
gcc47-pr50237.patch

Getting rid of the attribute constructor in libcpp/lex.c isn't that hard either.
Comment 30 ro@CeBiTec.Uni-Bielefeld.DE 2011-11-28 15:40:32 UTC
> Getting rid of the attribute constructor in libcpp/lex.c isn't that hard
> either.

... but doesn't help for the Go comparison failures.

	Rainer
Comment 31 Eric Botcazou 2011-12-01 20:25:27 UTC
> Getting rid of the attribute constructor in libcpp/lex.c isn't that hard
> either.

Right, I'd apply the patch in any case, this is a gratuitous portability issue.
Comment 32 Jakub Jelinek 2011-12-07 22:06:04 UTC
Author: jakub
Date: Wed Dec  7 22:05:59 2011
New Revision: 182090

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182090
Log:
	PR bootstrap/50237
	* internal.h (_cpp_init_lexer): New prototype.
	* init.c (init_library): Call it.
	* lex.c (init_vectorized_lexer): Remove constructor attribute,
	add inline keyword.
	(HAVE_init_vectorized_lexer): Define.
	(_cpp_init_lexer): New function.

Modified:
    trunk/libcpp/ChangeLog
    trunk/libcpp/init.c
    trunk/libcpp/internal.h
    trunk/libcpp/lex.c
Comment 33 Andrew Pinski 2012-01-09 00:54:10 UTC
I now get this failure with gcc/go/go.o (and others) miscomparing.
I have a new version of binutils installed in the prefix but not currently in the PATH.
stage2 uses ctors and stage3 uses init_array.

Now my work around is just to put the new binutils in the PATH but that should not be needed.
Comment 34 Richard Biener 2012-01-09 14:31:30 UTC
Another possible fix is to drop autodetecting the feature (defaulting to
the old behavior) and requiring --enable-init_array at configure time.

HJ, please work on this, this is a real blocker.  I prefer the explicit
configure argument way for 4.7, we can switch to autodetection in a later
release.
Comment 35 Jakub Jelinek 2012-01-17 16:00:44 UTC
Created attachment 26352 [details]
gcc47-pr50237.patch

Untested patch.  For ia64 I've kept it (hopefully) as is, for other targets this
attempts to detect the missing linker support using as/ld/objdump.
There is no testing of the libc/dynamic linker though, what C libraries do support .init_array/.fini_array properly?  For glibc I'd say at least all >= 2.4, since 2.4 removed altogether support for configurations where linker didn't support .init_array, so perhaps we could AC_PREPROC_IFELSE and test __GLIBC__ and __GLIBC_MINOR__ macros.  What other OSes support .init_array properly and would like it be enabled by default when neither --enable-initfini-array nor --disable-initfini-array is specified?
Comment 36 Jakub Jelinek 2012-01-19 10:43:58 UTC
Author: jakub
Date: Thu Jan 19 10:43:54 2012
New Revision: 183299

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183299
Log:
	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.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/acinclude.m4
    trunk/gcc/config.gcc
    trunk/gcc/config/initfini-array.h
    trunk/gcc/configure
    trunk/gcc/configure.ac
Comment 37 Jakub Jelinek 2012-01-19 10:50:13 UTC
Rainer/Andrew, please test this in your configurations.
Comment 38 ro@CeBiTec.Uni-Bielefeld.DE 2012-01-19 16:08:44 UTC
> --- Comment #37 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-19 10:50:13 UTC ---
> Rainer/Andrew, please test this in your configurations.

I've just successfully completed i386-pc-solaris2.1[01] gas/gld
bootstraps without the previous --disable-initfini-array workaround.

Thanks for fixing this.

I'll check if support can unconditionally be enabled on Solaris if the
tools support it.

So far, ld -e 0 doesn't work:

ld: fatal: entry point symbol '0' is undefined

while omitting -e 0 gets a warning from gld:

gld-2.22: warning: cannot find entry symbol _start; defaulting to 0000000008048054

The latter is probably harmless, though, and we can just omit the -e 0
everwhere.

While gld does merge the .init_array.N/.fini_array.N sections, Sun ld
does not, so the test always fails if ld is in use.

(Recent?) Sun as on Solaris 10 and 11/x86 work, too.

On Solaris 11/SPARC, the test fails even with gas and gld 2.22:

> objdump -s -j .init_array conftest

conftest:     file format elf32-sparc-sol2

Contents of section .init_array:
 20054 48484848 44444444                    HHHHDDDD      

Still need to check why.

	Rainer
Comment 39 Jakub Jelinek 2012-01-19 16:17:29 UTC
(In reply to comment #38)
> So far, ld -e 0 doesn't work:

Well, if no Sun ld handles the section mixing right, it doesn't matter that much.  We could just:
  .text
  .globl _start
_start:
at the end of the assembly otherwise.

> (Recent?) Sun as on Solaris 10 and 11/x86 work, too.

It will still not default to --enable-initfini-array there, because of the glibc version check.  Does Solaris dynamic linker handle .init_array etc. right (e.g. the old H.J.'s testcase from configure if compiled with GNU ld 2.22 or later)?  If yes, from which versions?  Shall it be based on just target tripplets for Solaris?

> On Solaris 11/SPARC, the test fails even with gas and gld 2.22:
> 
> > objdump -s -j .init_array conftest
> 
> conftest:     file format elf32-sparc-sol2
> 
> Contents of section .init_array:
>  20054 48484848 44444444                    HHHHDDDD      

If it contains just two, then possibly the .ctors section has been kept around?
I'd guess that H.J's testcase wouldn't succeed either.

Anyway, marking this as fixed, details can be fixed up incrementally.
Comment 40 ro@CeBiTec.Uni-Bielefeld.DE 2012-01-19 16:27:44 UTC
> --- Comment #39 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-19 16:17:29 UTC ---
> (In reply to comment #38)
>> So far, ld -e 0 doesn't work:
>
> Well, if no Sun ld handles the section mixing right, it doesn't matter that

I've been in touch with the linker engineers about this issue, and they
are not convinced that this section merging is mandated by the ELF spec.

> much.  We could just:
>   .text
>   .globl _start
> _start:
> at the end of the assembly otherwise.

True.

>> (Recent?) Sun as on Solaris 10 and 11/x86 work, too.
>
> It will still not default to --enable-initfini-array there, because of the
> glibc version check.  Does Solaris dynamic linker handle .init_array etc. right

I know.

> (e.g. the old H.J.'s testcase from configure if compiled with GNU ld 2.22 or
> later)?  If yes, from which versions?  Shall it be based on just target
> tripplets for Solaris?

I'm about to change the glibc check for Solaris.  I'm pretty sure it
works right on Solaris 11, and probably also on (patched) versions of
Solaris 8 and up.  If this is something that has been introduced after
FCS, I'll perform the same ld version checking I did in other cases,
since ld and ld.so.1 are guaranteed to be upgraded in lockstep.

>> On Solaris 11/SPARC, the test fails even with gas and gld 2.22:
>> 
>> > objdump -s -j .init_array conftest
>> 
>> conftest:     file format elf32-sparc-sol2
>> 
>> Contents of section .init_array:
>>  20054 48484848 44444444                    HHHHDDDD      
>
> If it contains just two, then possibly the .ctors section has been kept around?
> I'd guess that H.J's testcase wouldn't succeed either.

Right, it aborts.

> Anyway, marking this as fixed, details can be fixed up incrementally.

Agreed, bootstrapping again out of the box is the primary issue of this PR.

	Rainer
Comment 41 Jakub Jelinek 2012-01-19 16:32:08 UTC
It isn't mandated by the ELF spec, but if the linker doesn't do that and either keeps .ctors and .init_array etc. separate, or merges them but without ensuring the right order, ctor/dtor priorities won't work correctly.
Comment 42 ro@CeBiTec.Uni-Bielefeld.DE 2012-01-19 16:36:56 UTC
> --- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-19 16:32:08 UTC ---
> It isn't mandated by the ELF spec, but if the linker doesn't do that and either
> keeps .ctors and .init_array etc. separate, or merges them but without ensuring
> the right order, ctor/dtor priorities won't work correctly.

I know.  The question is if adding this gld extension to Sun ld could be
justified and if there's a spec the Oracle guys could use without
reading the gld code.  Especially in Solaris 11, many gld command line
options and features have been added this name to improve compatibility.

IIRC, there are other cases where gld merges sections when Sun ld does
not.

	Rainer
Comment 43 Andrew Pinski 2012-01-19 23:37:52 UTC
(In reply to comment #37)
> Rainer/Andrew, please test this in your configurations.

Yes it works for me now.  Thanks for fixing this issue.
Comment 44 Jing Yu 2012-02-22 22:04:45 UTC
Author: jingyu
Date: Wed Feb 22 22:04:39 2012
New Revision: 184493

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184493
Log:
2012-02-21   Jing Yu  <jingyu@google.com>

	Google Ref 47894
	Backport from mainline r177933, r175181, r177963, r178116, r183299.

	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.
	* crtstuff.c: Don't generate .ctors nor .dtors sections if
	USE_INITFINI_ARRAY is defined.
	* output.h (default_elf_init_array_asm_out_constructor): New.
	(default_elf_fini_array_asm_out_destructor): Likewise.
	* varasm.c (elf_init_array_section): Likewise.
	(elf_fini_array_section): Likewise.
	(get_elf_initfini_array_priority_section): Likewise.
	(default_elf_init_array_asm_out_constructor): Likewise.
	(default_elf_fini_array_asm_out_destructor): Likewise.
	* config/initfini-array.h: New.
	
	2011-06-18  H.J. Lu  <hongjiu.lu@intel.com>
	PR other/49325
	* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Properly check if
	.init_array can be used with .ctors on targets.
	* configure: Regenerated.

	2011-08-22  H.J. Lu  <hongjiu.lu@intel.com>
	* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Error if __ELF__ isn't
	defined.
	* configure: Regenerated.

	2011-08-26  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
	PR target/50166
	* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Check count in main.
	* configure: Regenerate.

	2012-01-19  Jakub Jelinek  <jakub@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.


Added:
    branches/google/gcc-4_6/gcc/config/initfini-array.h
Modified:
    branches/google/gcc-4_6/gcc/ChangeLog.google-4_6
    branches/google/gcc-4_6/gcc/acinclude.m4
    branches/google/gcc-4_6/gcc/configure
    branches/google/gcc-4_6/gcc/configure.ac
    branches/google/gcc-4_6/gcc/crtstuff.c
    branches/google/gcc-4_6/gcc/output.h
    branches/google/gcc-4_6/gcc/varasm.c
Comment 45 Jing Yu 2012-02-22 22:26:45 UTC
Author: jingyu
Date: Wed Feb 22 22:26:40 2012
New Revision: 184494

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184494
Log:
2012-02-21   Jing Yu  <jingyu@google.com>

	Bakcport r175181, r177963, r178116, r183299 from mainline.

	2011-06-18  H.J. Lu  <hongjiu.lu@intel.com>
	PR other/49325
	* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Properly check if
	.init_array can be used with .ctors on targets.
	* configure: Regenerated.

	2011-08-22  H.J. Lu  <hongjiu.lu@intel.com>
	* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Error if __ELF__ isn't
	defined.
	* configure: Regenerated.

	2011-08-26  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
	PR target/50166
	* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Check count in main.
	* configure: Regenerate.

	2012-01-19  Jakub Jelinek  <jakub@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.


Modified:
    branches/google/gcc-4_6_2-mobile/gcc/ChangeLog.google-4_6
    branches/google/gcc-4_6_2-mobile/gcc/acinclude.m4
    branches/google/gcc-4_6_2-mobile/gcc/config.gcc
    branches/google/gcc-4_6_2-mobile/gcc/config/initfini-array.h
    branches/google/gcc-4_6_2-mobile/gcc/configure
    branches/google/gcc-4_6_2-mobile/gcc/configure.ac