Re: -ffunction-sections, -fdata-sections and -Wl,--gc-sections

From: Ian Lepore <ian_at_FreeBSD.org>
Date: Tue, 17 Sep 2013 18:26:42 -0600
On Tue, 2013-09-17 at 16:31 -0700, Adrian Chadd wrote:
> On 17 September 2013 16:22, Ian Lepore <ian_at_freebsd.org> wrote:
> 
> > On Tue, 2013-09-17 at 14:56 -0700, Adrian Chadd wrote:
> > > ... I'd rather see if we can actually separate out things some more so
> > > these builds can shrink.
> > >
> > > Eg, if there's malloc related functions that aren't used, maybe we should
> > > break malloc down into a directory full of functions.
> > >
> >
> > Why is that better than using this automated solution?
> >
> 
> Not everyone is going to run clang on their target development platform? :-)
> 
> Personally I'd rather structure my work to behave better instead of doing
> something that relies on a specific tool/suite to be able to optimise.

The original mail began describing the feature with "GCC and Clang
support the -ffunction-sections and -fdata-sections flags."

I would much rather have the tools perform this mundane task, and keep
the source code maintainable rather than artificially broken into a
zillion tiny pieces.

I'm interested in it for $work.  We have lots and lots of .a libraries
that get linked to make an app that also uses shared libs at runtime
(libc et. al.).  We often have large .o files with lots of C++ methods
of a class in it, and only 2 or 3 of the methods may be actually used in
a given app.    I haven't tested it yet, but the way I'm picturing this
working, we should get good savings because unused functions from all
our .a libs won't get linked in, even though the overall app isn't
static-linked.

-- Ian
Received on Tue Sep 17 2013 - 22:26:48 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:41 UTC