This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Define [CD]TORS_SECTION_ASM_OP on Solaris/x86 with Sun ld
- From: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- To: gcc-patches at gcc dot gnu dot org
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>
- Date: Mon, 11 Jul 2011 18:34:27 +0200
- Subject: Define [CD]TORS_SECTION_ASM_OP on Solaris/x86 with Sun ld
While investigating why many libmudflap execution tests failed on
Solaris 11/x86 with Sun ld, but succeeded on Solaris 11/SPARC, I came
across the following:
The first failure is fail17-frag. With MUDFLAP_OPTIONS=-trace-calls, I see
mf: __mfwrap_strcpy
mf: check ptr=8050f8c b=995 size=10 read location=`(strcpy src)'
mf: violation pc=fee8894d location=(strcpy src) type=1 ptr=8050f8c size=10
*******
mudflap violation 1 (check/read): time=1310040104.249932 ptr=8050f8c size=10
pc=fee8894d location=`(strcpy src)'
The constant string isn't ever registered here, thus the failure.
With gld instead, I see no failure
mf: __mfwrap_strcpy
mf: check ptr=8048bac b=747 size=10 read location=`(strcpy src)'
and the string is registered very early:
mf: register ptr=0 size=1 type=0 name='NULL'
mf: register ptr=8048bac size=10 type=4 name='string literal'
This registration is from tree-mudflap.c (mudflap_enqueue_constant),
emitted at the end of mudflap_finish_file via
cgraph_build_static_cdtor ('I', ctor_statements,
MAX_RESERVED_INIT_PRIORITY-1);
With gld, the registration function _GLOBAL__sub_I_00099_0_main is
entered into a .ctors section, but with Sun ld I find separate .ctors
and .ctors.65436 sections. varasm.c (get_cdtor_priority_section), which
is called by default_named_section_asm_out_constructor, states:
/* ??? This only works reliably with the GNU linker. */
This is obviously true: Sun ld doesn't coalesce different .ctors.N
sections, thus the contructor isn't called.
On Solaris 11/SPARC instead, CTORS_SECTION_ASM_OP is defined in
sparc/sysv4.h, and thus default_ctor_section_asm_out_constructor is
called.
The obvious solution is to define [CD]TORS_SECTION_ASM_OP on Solaris/x86
with Sun ld, too. And indeed this fixes all remaining libmudflap
failures.
On the other hand, there's the question why tree-mudflap.c tries to
create a constructor with a non-default priority on a platform with
SUPPORTS_INIT_PRIORITY == 0 or at all: it seems that all is fine even
with init_priority ignored. Either mudflap_enqueue_constant should
check for this condition, or at least the middle-end should emit an
error or a warning in this case.
I've bootstrapped the following patch without regressions on
i386-pc-solaris2.11 (Sun as/ld) and i386-pc-solaris2.8 (GNU as/ld)
without regressions.
Installed on mainline.
Rainer
2011-07-08 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
* config/i386/sol2.h [!USE_GLD] (CTORS_SECTION_ASM_OP): Define.
(DTORS_SECTION_ASM_OP): Define.
diff --git a/gcc/config/i386/sol2.h b/gcc/config/i386/sol2.h
--- a/gcc/config/i386/sol2.h
+++ b/gcc/config/i386/sol2.h
@@ -152,6 +152,13 @@ along with GCC; see the file COPYING3.
#undef TARGET_ASM_NAMED_SECTION
#define TARGET_ASM_NAMED_SECTION i386_solaris_elf_named_section
+/* Unlike GNU ld, Sun ld doesn't coalesce .ctors.N/.dtors.N sections, so
+ inhibit their creation. Also cf. sparc/sysv4.h. */
+#ifndef USE_GLD
+#define CTORS_SECTION_ASM_OP "\t.section\t.ctors, \"aw\""
+#define DTORS_SECTION_ASM_OP "\t.section\t.dtors, \"aw\""
+#endif
+
/* We do not need NT_VERSION notes. */
#undef X86_FILE_START_VERSION_DIRECTIVE
#define X86_FILE_START_VERSION_DIRECTIVE false
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University