[build] Support init priority on Solaris

Rainer Orth ro@CeBiTec.Uni-Bielefeld.DE
Wed Oct 7 14:38:00 GMT 2015


Recent versions of Solaris 12 ld have gained support for constructor
priority.  It slightly differs from GNU ld in that .ctors.N/.dtors.N
sections aren't handled (no need for backwards compatibility) and
.ctors/.dtors aren't merged into .init_array/.fini_array, but kept
separate, though their relative execution order remains the same.

The following patch enables init_priority on Solaris if the necessary
prerequisites are met:

* With the native assemblers, the syntax is slightly different (e.g.
  @progbits on Solaris/x86 while gas always understands both %progbits
  and @progbits).

* When Solaris ld is in use, the test needs to be modified to remove the
  .[cd]tors{,.N} sections as explained above.

Since the configure check may now depend on the assembler and linker
used, it could in theory affect configurations not using gld.  Unless
I'm mistaken, there are only AIX, HP-UX, and Mac OS X left, all of which
define SUPPORTS_INIT_PRIORITY directly and ignore
HAVE_INITFINI_ARRAY_SUPPORT.  The latter is now always defined with a
value, and I've modifed the few users accordingly.  IA64
crt{begin,end}.S are the only non-common ones: I haven't tested the
patch there, but believe it's obvious.

When testing on Solaris/SPARC with the native as, initially bootstrap
broke because all .init_array etc. sections were marked SHT_PROGBITS.
Once I heeded SECTION_NOTYPE, those errors went away.  While doing so, I
noticed that HAVE_AS_SPARC_NOBITS is now superfluous since even the
Solaris 10 FCS as supports #nobits.

Initially, Solaris/SPARC testing gld didn't detect working linker
support.  It turns out that the gld configure probes the build compiler
to enable .init_array/.fini_array support.  This test succeeds on
Solaris/x86, but fails on Solaris/SPARC.  I haven't yet investigated why
this happens, and don't fully understand why the test is necessary in
the first place.  To do proper testing with gld, I've simply configured
binutils with --enable-initfini-array.

Bootstrapped without regressions on i386-pc-solaris2.1[1-2],
sparc-sun-solaris2.1[0-2] with as/ld and gas/gld, and
x86_64-pc-linux-gnu.

Ok for mainline?  I'm not really comfortable with backporting such a
change to the gcc-5 branch, though.

	Rainer


2015-09-10  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	libgcc:
	* config/ia64/crtbegin.S: Check HAVE_INITFINI_ARRAY_SUPPORT
	value.
	* config/ia64/crtend.S: Likewise.

	gcc:
	* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Allow for differences in
	assembler syntax.
	Support Solaris ld.
	Define HAVE_INITFINI_ARRAY_SUPPORT as 0/1.

	* config/sol2.h (SUPPORTS_INIT_PRIORITY): Define to
	HAVE_INITFINI_ARRAY_SUPPORT.
	* config/initfini-array.h: Check HAVE_INITFINI_ARRAY_SUPPORT
	value.

	* configure.ac (gcc_cv_as_sparc_nobits): Remove.
	* config/sparc/sparc.c (sparc_solaris_elf_asm_named_section):
	Don't check HAVE_AS_SPARC_NOBITS.
	Heed SECTION_NOTYPE.

	* configure: Regenerate.
	* config.in: Regenerate.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sol2-init_priority.patch
Type: text/x-patch
Size: 7654 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20151007/440537b9/attachment.bin>
-------------- next part --------------

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


More information about the Gcc-patches mailing list