public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections
Date: Fri, 22 Jul 2011 12:37:00 -0000	[thread overview]
Message-ID: <20110722123042.GB2687@tyan-ft48-01.lab.bos.redhat.com> (raw)
In-Reply-To: <CAMe9rOof=V4c89715u-Z=zG8kqADrupMaemnjuYPJA-xPQaKxg@mail.gmail.com>

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

  parent reply	other threads:[~2011-07-22 12:31 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-21 18:40 H.J. Lu
2011-03-31 15:15 ` H.J. Lu
2011-04-14 19:11   ` H.J. Lu
2011-04-26 13:08   ` H.J. Lu
2011-05-18 17:30     ` H.J. Lu
2011-06-01 23:30       ` Carrot Wei
2011-06-03  4:31       ` H.J. Lu
2011-06-03 12:31         ` Richard Guenther
2011-06-03 12:52           ` H.J. Lu
2011-06-19 20:02             ` H.J. Lu
2011-06-19 21:31               ` Uros Bizjak
2011-07-22 12:31                 ` H.J. Lu
2011-07-22 12:36                   ` Rainer Orth
2011-07-22 12:36                     ` H.J. Lu
2011-07-22 13:20                       ` Rainer Orth
2011-07-22 12:37                   ` Jakub Jelinek [this message]
2011-07-22 13:21                     ` Joseph S. Myers
2011-07-22 13:29                     ` H.J. Lu
2011-07-22 14:17                       ` H.J. Lu
2011-07-22 14:55                         ` H.J. Lu
2011-08-06 14:51                           ` H.J. Lu
2011-08-09 14:32                             ` H.J. Lu
2011-08-14 19:20                               ` H.J. Lu
2011-08-19 10:05                           ` Jakub Jelinek
2011-08-19 14:58                             ` H.J. Lu
2011-08-19 15:54                               ` Jakub Jelinek
2011-08-20 21:16                                 ` H.J. Lu
2012-03-19 20:35                                   ` DJ Delorie
2012-03-19 20:40                                     ` Andrew Pinski
2012-03-19 20:42                                       ` DJ Delorie
2011-07-01 14:12               ` H.J. Lu
2011-06-03 17:13           ` Michael Eager
2011-08-22  7:39 David Edelsohn
2011-08-22  7:44 ` H.J. Lu
2011-08-22  7:46   ` Jakub Jelinek
2011-08-22 14:23     ` H.J. Lu
2011-08-22 15:27       ` H.J. Lu
2011-08-22 15:46         ` Paolo Bonzini
2011-08-22 17:37     ` H.J. Lu
2011-08-22 18:33       ` H.J. Lu
2011-08-22 19:12       ` Joseph S. Myers
2011-08-22 19:19         ` H.J. Lu
2011-08-22 19:38           ` Joseph S. Myers
2011-08-22 20:50             ` H.J. Lu
2011-08-22  7:46   ` David Edelsohn
2011-08-22 16:26 ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110722123042.GB2687@tyan-ft48-01.lab.bos.redhat.com \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hjl.tools@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).