public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Jozef Lawrynowicz <jozef.l@mittosystems.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 3/3] libgcc: Implement TARGET_LIBGCC_REMOVE_DSO_HANDLE
Date: Wed, 11 Dec 2019 18:44:00 -0000	[thread overview]
Message-ID: <f8fba8224aa49a0ecc08295b38ee5c44cde26163.camel@redhat.com> (raw)
In-Reply-To: <20191211114933.6ec11b87@jozef-kubuntu>

On Wed, 2019-12-11 at 11:49 +0000, Jozef Lawrynowicz wrote:
> On Mon, 9 Dec 2019 13:05:22 +0000
> Jozef Lawrynowicz <jozef.l@mittosystems.com> wrote:
> 
> > On Sat, 07 Dec 2019 11:27:54 -0700
> > Jeff Law <law@redhat.com> wrote:
> > 
> > > On Wed, 2019-11-06 at 16:19 +0000, Jozef Lawrynowicz wrote:  
> > > > From 7bc0971d2936ebe71e7b7d3d805cf1bbf9f9f5af Mon Sep 17
> > > > 00:00:00 2001
> > > > From: Jozef Lawrynowicz <jozef.l@mittosystems.com>
> > > > Date: Mon, 4 Nov 2019 17:38:13 +0000
> > > > Subject: [PATCH 3/3] libgcc: Implement
> > > > TARGET_LIBGCC_REMOVE_DSO_HANDLE
> > > > 
> > > > gcc/ChangeLog:
> > > > 
> > > > 2019-11-06  Jozef Lawrynowicz  <jozef.l@mittosystems.com>
> > > > 
> > > > 	* doc/tm.texi: Regenerate.
> > > > 	* doc/tm.texi.in: Define
> > > > TARGET_LIBGCC_REMOVE_DSO_HANDLE.
> > > > 
> > > > libgcc/ChangeLog:
> > > > 
> > > > 2019-11-06  Jozef Lawrynowicz  <jozef.l@mittosystems.com>
> > > > 
> > > > 	* crtstuff.c: Don't declare __dso_handle if
> > > > 	TARGET_LIBGCC_REMOVE_DSO_HANDLE is defined.    
> > > Presumably you'll switch this on for your bare elf target
> > > configuration?  
> > 
> > Yep that's the plan. I originally didn't include the target changes
> > in
> > this patch since other target changes (disabling __cxa_atexit) were
> > required for
> > the removal of __dso_handle to be OK.
> > 
> > > Are there other things, particularly related to shared library
> > > support,
> > > that we wouldn't need to use as well?  The reason I ask is I'm
> > > trying
> > > to figure out if REMOVE_DSO_HANDLE is the right name or if we
> > > should
> > > generalize it to a name that indicates shared libraries in
> > > general
> > > aren't supported on the target.  
> > 
> > CRTSTUFFS_O is defined when compiling shared versions of
> > crt{begin,end} and
> > handles an extra case in crtstuff.c where there's some shared
> > library related
> > functionality we don't need on MSP430.
> > 
> > But when CRTSTUFFS_O is undefined __dso_handle is still declared -
> > to 0. The
> > comment gives some additional insight:
> > 
> > /* Declare the __dso_handle variable.  It should have a unique
> > value  
> >    in every shared-object; in a main program its value is
> > zero.  The  
> >    object should in any case be protected.  This means the
> > instance   
> >    in one DSO or the main program is not used in another
> > object.  The 
> >    dynamic linker takes care of
> > this.  */                             
> > 
> > I haven't noticed any further shared library-related bloat coming
> > from libgcc.
> > 
> > I think a better way of solving this problem is just to check
> > DEFAULT_USE_CXA_ATEXIT rather than adding this new macro. If
> > __cxa_atexit is
> > not enabled then as far as I understand __dso_handle serves no
> > purpose.
> > DEFAULT_USE_CXA_ATEXIT is defined at configure time for any targets
> > that want
> > __cxa_atexit support.
> > 
> > A quick bootstrap and test of dg.exp on x86_64-pc-linux-gnu shows
> > no issues
> > with the following:
> > 
> > > diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
> > > index ae6328d317d..349f8191e61 100644
> > > --- a/libgcc/crtstuff.c
> > > +++ b/libgcc/crtstuff.c
> > > @@ -340,8 +340,10 @@ extern void *__dso_handle __attribute__
> > > ((__visibility__ ("hidden")));
> > >  #ifdef CRTSTUFFS_O
> > >  void *__dso_handle = &__dso_handle;
> > >  #else
> > > +#if DEFAULT_USE_CXA_ATEXIT
> > >  void *__dso_handle = 0;
> > >  #endif
> > > +#endif
> > >  
> > >  /* The __cxa_finalize function may not be available so we use
> > > only a
> > >     weak declaration.  */  
> > 
> > I'll put that patch through some more rigorous testing.
> 
> Successfully bootstrapped and regtested the attached patch for
> x86_64-pc-linux-gnu (where DEFAULT_USE_CXA_ATEXIT is set to 1) and
> the proposed
> msp430-elfbare target (where DEFAULT_USE_CXA_ATEXIT is set to 0).
> 
> > libgcc/ChangeLog:
> > 
> > 2019-12-11  Jozef Lawrynowicz  <jozef.l@mittosystems.com>
> > 
> > 	* crtstuff.c: Declare __dso_handle only if
> > DEFAULT_USE_CXA_ATEXIT is
> > 	true.
OK
jeff

ps.  Sorry about the formatting.  Had to switch MUAs last week and
still haven't gotten all the kinks worked out.

      reply	other threads:[~2019-12-11 18:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-06 16:14 [PATCH 0/3] libgcc/crtstuff.c tweaks to reduce code size Jozef Lawrynowicz
2019-11-06 16:16 ` [PATCH 1/3] libgcc: Add --disable-eh-frame-registry configure option Jozef Lawrynowicz
2019-11-06 21:05   ` Jozef Lawrynowicz
2019-11-06 16:17 ` [PATCH 2/3] libgcc: Dont define __do_global_dtors_aux if it will be empty Jozef Lawrynowicz
2019-12-07 18:29   ` Jeff Law
2019-12-09 12:19   ` Tobias Burnus
2019-12-09 12:24     ` Jozef Lawrynowicz
2019-11-06 16:19 ` [PATCH 3/3] libgcc: Implement TARGET_LIBGCC_REMOVE_DSO_HANDLE Jozef Lawrynowicz
2019-12-07 18:28   ` Jeff Law
2019-12-09 13:05     ` Jozef Lawrynowicz
2019-12-11 11:49       ` Jozef Lawrynowicz
2019-12-11 18:44         ` Jeff Law [this message]

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=f8fba8224aa49a0ecc08295b38ee5c44cde26163.camel@redhat.com \
    --to=law@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jozef.l@mittosystems.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).