On Fri, 08 Nov 2019 22:59:18 +0900
Oleg Endo <oleg.e...@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.

> Cheers,
> Oleg

Reply via email to