From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24330 invoked by alias); 22 Jul 2011 13:03:36 -0000 Received: (qmail 24321 invoked by uid 22791); 22 Jul 2011 13:03:35 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_GM,TW_PM X-Spam-Check-By: sourceware.org Received: from mail-qw0-f47.google.com (HELO mail-qw0-f47.google.com) (209.85.216.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 22 Jul 2011 13:03:22 +0000 Received: by qwh5 with SMTP id 5so1324896qwh.20 for ; Fri, 22 Jul 2011 06:03:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.86.72 with SMTP id r8mr1203859qcl.84.1311339800330; Fri, 22 Jul 2011 06:03:20 -0700 (PDT) Received: by 10.229.98.193 with HTTP; Fri, 22 Jul 2011 06:03:20 -0700 (PDT) In-Reply-To: <20110722123042.GB2687@tyan-ft48-01.lab.bos.redhat.com> References: <20110722123042.GB2687@tyan-ft48-01.lab.bos.redhat.com> Date: Fri, 22 Jul 2011 13:29:00 -0000 Message-ID: Subject: Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections From: "H.J. Lu" To: Jakub Jelinek Cc: GCC Patches Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg01951.txt.bz2 On Fri, Jul 22, 2011 at 5:30 AM, Jakub Jelinek wrote: > On Fri, Jul 22, 2011 at 04:59:28AM -0700, H.J. Lu wrote: >> @@ -2660,6 +2664,7 @@ esac >> =A0case ${target} in >> =A0i[34567]86-*-linux* | x86_64-*-linux*) >> =A0 =A0 =A0 tmake_file=3D"${tmake_file} i386/t-pmm_malloc i386/t-i386" >> + =A0 =A0 use_initfini_array=3Dyes >> =A0 =A0 =A0 ;; >> =A0i[34567]86-*-* | x86_64-*-*) >> =A0 =A0 =A0 tmake_file=3D"${tmake_file} i386/t-gmm_malloc i386/t-i386" > > What is i?86/x86_64 specific on it? =A0Don't most other glibc targets > want to use it too, perhaps with some arch specific tweaks? I do have a patch for all ELF targets: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01416.html It touches many targets. . But I only have one feedback from one target maintainer. I don't know how long it will take to review it. >> --- /dev/null >> +++ b/gcc/config/initfini-array.c > > This is ugly. =A0varasm.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.). =A0The sections probab= ly > can be created only the first time you actually need them. I will do that. >> --- a/gcc/crtstuff.c >> +++ b/gcc/crtstuff.c >> @@ -189,6 +190,9 @@ typedef void (*func_ptr) (void); >> =A0 =A0 refer to only the __CTOR_END__ symbol in crtend.o and the __DTOR= _LIST__ >> =A0 =A0 symbol in crtbegin.o, where they are defined. =A0*/ >> >> +/* No need for .ctors/.dtors section if linker can place them in >> + =A0 .init_array/.fini_array section. =A0*/ >> +#ifndef NO_CTORS_DTORS_SECTIONS >> =A0/* The -1 is a flag to __do_global_[cd]tors indicating that this table >> =A0 =A0 does not start with a count of elements. =A0*/ >> =A0#ifdef CTOR_LIST_BEGIN >> @@ -219,6 +223,7 @@ STATIC func_ptr __DTOR_LIST__[1] >> =A0 =A0__attribute__((section(".dtors"), aligned(sizeof(func_ptr)))) >> =A0 =A0=3D { (func_ptr) (-1) }; >> =A0#endif /* __DTOR_LIST__ alternatives */ >> +#endif /* NO_CTORS_DTORS_SECTIONS */ >> >> =A0#ifdef USE_EH_FRAME_REGISTRY >> =A0/* Stick a label at the beginning of the frame unwind info so we can = register >> @@ -489,6 +494,9 @@ __do_global_ctors_1(void) >> >> =A0#elif defined(CRT_END) /* ! CRT_BEGIN */ >> >> +/* No need for .ctors/.dtors section if linker can place them in >> + =A0 .init_array/.fini_array section. =A0*/ >> +#ifndef NO_CTORS_DTORS_SECTIONS >> =A0/* Put a word containing zero at the end of each of our two lists of = function >> =A0 =A0 addresses. =A0Note that the words defined here go into the .ctor= s and .dtors >> =A0 =A0 sections of the crtend.o file, and since that file is always lin= ked in >> @@ -534,6 +542,7 @@ STATIC func_ptr __DTOR_END__[1] >> =A0 =A0__attribute__((used, section(".dtors"), aligned(sizeof(func_ptr))= )) >> =A0 =A0=3D { (func_ptr) 0 }; >> =A0#endif >> +#endif /* NO_CTORS_DTORS_SECTIONS */ >> >> =A0#ifdef EH_FRAME_SECTION_NAME >> =A0/* Terminate the frame unwind info section with a 4byte 0 as a sentin= el; > > I don't see how you can do this. =A0It 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. crtstuff.c is used to generate crt*.o, which is the part of GCC. You only = use it with the GCC you are using. Since your GCC doesn't put anything in .ctors/.dtors section, you don't need them. As for .o files generated by old GCCs, that is the linker test, use_initfini_array, is for. The newer l= inker can put input .ctors/.dtors sections in output .init_array/,fini_array sect= ions. --=20 H.J.