From patchwork Mon Jul 11 16:34:27 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rainer Orth X-Patchwork-Id: 104247 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 6B060B6F18 for ; Tue, 12 Jul 2011 02:34:50 +1000 (EST) Received: (qmail 23905 invoked by alias); 11 Jul 2011 16:34:47 -0000 Received: (qmail 23756 invoked by uid 22791); 11 Jul 2011 16:34:46 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL, BAYES_00, TW_MF, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from snape.CeBiTec.Uni-Bielefeld.DE (HELO smtp-relay.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Jul 2011 16:34:32 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 98F91C2C; Mon, 11 Jul 2011 18:34:30 +0200 (CEST) Received: from smtp-relay.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ND0xPadfJd0p; Mon, 11 Jul 2011 18:34:28 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (manam.CeBiTec.Uni-Bielefeld.DE [129.70.161.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id 0B759C2B; Mon, 11 Jul 2011 18:34:28 +0200 (CEST) Received: (from ro@localhost) by manam.CeBiTec.Uni-Bielefeld.DE (8.14.4+Sun/8.14.4/Submit) id p6BGYR0C006098; Mon, 11 Jul 2011 18:34:27 +0200 (MEST) From: Rainer Orth To: gcc-patches@gcc.gnu.org Cc: "Frank Ch. Eigler" Subject: Define [CD]TORS_SECTION_ASM_OP on Solaris/x86 with Sun ld Date: Mon, 11 Jul 2011 18:34:27 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (usg-unix-v) MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org 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 * 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