public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jozef Lawrynowicz <jozef.l@mittosystems.com>
To: Oleg Endo <oleg.endo@t-online.de>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 0/4][MSP430] Tweaks to default configuration to reduce code size
Date: Fri, 08 Nov 2019 14:32:00 -0000	[thread overview]
Message-ID: <20191108143232.29fb32cc@jozef-kubuntu> (raw)
In-Reply-To: <c88b54774f4e6e1841400dd215c3d2d41ae33a79.camel@t-online.de>

On Fri, 08 Nov 2019 22:59:18 +0900
Oleg Endo <oleg.endo@t-online.de> wrote:

> On Fri, 2019-11-08 at 13:27 +0000, Jozef Lawrynowicz wrote:
> > 
> > Yes, I should have used -flto in my examples. But it doesn't help remove these
> > CRT library functions which are normally either directly added to the
> > list of functions to run before main (via .init, .ctors or .init_array) or used
> > in functions which are themselves added to this list.
> > 
> > The unnecessary functions we want to remove are:
> >   deregister_tm_clones
> >   register_tm_clones
> >   __do_global_dtors_aux
> >   frame_dummy
> > LTO can't remove any of them.
> >   
> 
> Ah, right, good point.  That's not MSP430 specific actually.  For those
> things I usually have custom init code, which also does other things
> occasionally.  Stripping off global dtors is then an option in the
> build system which takes care of it (in my case, I do it by modifying
> the generated linker script).
> 
> But again, as with the exceptions, it might be better to implement
> these kind of things outside of the compiler, e.g. by building the app
> with -nostartfiles -nodefaultlibs and providing your own substitutes.

I just don't think we need to be putting up this high barrier to entry for users
who want reduced code size but are building GCC from source.

With these changes users are getting a highly size-optimized runtime library
(14 bytes for a program that gets you to main() is always nice to see) out of
the box, by simply removing features that do not make sense on the target, and
they don't have to faff with any extra options.

The size of the CRT code has been a long standing complaint and is some part of
the reason a large chunk of the MSP430 user base still uses "mspgcc" which is
the old downstream GCC port of the target, which hasn't has any development
since 2012.

> 
> Another option is to patch those things in using the OS part of the
> target triplet.

Interesting idea. Something like msp430-unknown-min(imum)? The thing is even
with these changes the target is still ELF compliant.

Although I guess supplying a configuration which disables exceptions is not
very ELF-y.

Thanks,
Jozef
> 
> Cheers,
> Oleg
> 

      reply	other threads:[~2019-11-08 14:32 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-07 21:31 Jozef Lawrynowicz
2019-11-07 21:34 ` [PATCH 1/4] MSP430: Disable TM clone registry by default Jozef Lawrynowicz
2019-11-17 19:32   ` Jeff Law
2019-11-24 14:22     ` Jozef Lawrynowicz
2019-11-24 17:24       ` Jeff Law
2019-11-24 17:55         ` Jozef Lawrynowicz
2019-11-07 21:37 ` [PATCH 2/4] MSP430: Disable exception handling by default for C++ Jozef Lawrynowicz
2019-11-08  0:07   ` Oleg Endo
2019-11-08 13:26     ` Jozef Lawrynowicz
2019-11-12 21:13       ` Richard Sandiford
2019-11-27 13:51         ` Jozef Lawrynowicz
2019-11-07 21:39 ` [PATCH 3/4] MSP430: Disable __cxa_atexit Jozef Lawrynowicz
2019-11-07 21:41 ` [PATCH 4/4] MSP430: Deprecate -minrt option Jozef Lawrynowicz
2019-11-17 21:02   ` Jeff Law
2019-11-24 16:38     ` Jozef Lawrynowicz
2019-11-08 12:14 ` [PATCH 0/4][MSP430] Tweaks to default configuration to reduce code size Oleg Endo
2019-11-08 13:27   ` Jozef Lawrynowicz
2019-11-08 13:59     ` Oleg Endo
2019-11-08 14:32       ` Jozef Lawrynowicz [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=20191108143232.29fb32cc@jozef-kubuntu \
    --to=jozef.l@mittosystems.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=oleg.endo@t-online.de \
    /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).