From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17958 invoked by alias); 22 Jul 2011 12:31:06 -0000 Received: (qmail 17944 invoked by uid 22791); 22 Jul 2011 12:31:05 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_GM,TW_PM X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 22 Jul 2011 12:30:45 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p6MCUikW028451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Jul 2011 08:30:44 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p6MCUhJ7028107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2011 08:30:44 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (localhost.localdomain [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id p6MCUg8Q013384; Fri, 22 Jul 2011 14:30:42 +0200 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id p6MCUg8c013011; Fri, 22 Jul 2011 14:30:42 +0200 Date: Fri, 22 Jul 2011 12:37:00 -0000 From: Jakub Jelinek To: "H.J. Lu" Cc: GCC Patches Subject: Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections Message-ID: <20110722123042.GB2687@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg01942.txt.bz2 On Fri, Jul 22, 2011 at 04:59:28AM -0700, H.J. Lu wrote: > @@ -2660,6 +2664,7 @@ esac > case ${target} in > i[34567]86-*-linux* | x86_64-*-linux*) > tmake_file="${tmake_file} i386/t-pmm_malloc i386/t-i386" > + use_initfini_array=yes > ;; > i[34567]86-*-* | x86_64-*-*) > tmake_file="${tmake_file} i386/t-gmm_malloc i386/t-i386" What is i?86/x86_64 specific on it? Don't most other glibc targets want to use it too, perhaps with some arch specific tweaks? > --- /dev/null > +++ b/gcc/config/initfini-array.c This is ugly. varasm.c already has lots of ELF specific code, simply put them there as well and only let configury set some macro which will allow targets to choose which of the implementations in the generic code they want to use (or if they want their own which e.g. calls the generic routine and does something additional to it etc.). The sections probably can be created only the first time you actually need them. > --- a/gcc/crtstuff.c > +++ b/gcc/crtstuff.c > @@ -189,6 +190,9 @@ typedef void (*func_ptr) (void); > refer to only the __CTOR_END__ symbol in crtend.o and the __DTOR_LIST__ > symbol in crtbegin.o, where they are defined. */ > > +/* No need for .ctors/.dtors section if linker can place them in > + .init_array/.fini_array section. */ > +#ifndef NO_CTORS_DTORS_SECTIONS > /* The -1 is a flag to __do_global_[cd]tors indicating that this table > does not start with a count of elements. */ > #ifdef CTOR_LIST_BEGIN > @@ -219,6 +223,7 @@ STATIC func_ptr __DTOR_LIST__[1] > __attribute__((section(".dtors"), aligned(sizeof(func_ptr)))) > = { (func_ptr) (-1) }; > #endif /* __DTOR_LIST__ alternatives */ > +#endif /* NO_CTORS_DTORS_SECTIONS */ > > #ifdef USE_EH_FRAME_REGISTRY > /* Stick a label at the beginning of the frame unwind info so we can register > @@ -489,6 +494,9 @@ __do_global_ctors_1(void) > > #elif defined(CRT_END) /* ! CRT_BEGIN */ > > +/* No need for .ctors/.dtors section if linker can place them in > + .init_array/.fini_array section. */ > +#ifndef NO_CTORS_DTORS_SECTIONS > /* Put a word containing zero at the end of each of our two lists of function > addresses. Note that the words defined here go into the .ctors and .dtors > sections of the crtend.o file, and since that file is always linked in > @@ -534,6 +542,7 @@ STATIC func_ptr __DTOR_END__[1] > __attribute__((used, section(".dtors"), aligned(sizeof(func_ptr)))) > = { (func_ptr) 0 }; > #endif > +#endif /* NO_CTORS_DTORS_SECTIONS */ > > #ifdef EH_FRAME_SECTION_NAME > /* Terminate the frame unwind info section with a 4byte 0 as a sentinel; I don't see how you can do this. It would IMO break any time you link code built by different gcc versions where some code emitted by the older gcc used .ctors or .dtors. Jakub