[systemd-devel] [PATCH] build-sys: remove --gc-sections to fix debugging

Gustavo Sverzut Barbieri gustavo.barbieri at intel.com
Wed Nov 26 09:40:58 PST 2014


On Wed, Nov 26, 2014 at 06:33:31PM +0100, Lennart Poettering wrote:
> On Wed, 26.11.14 15:16, Gustavo Sverzut Barbieri (gustavo.barbieri at intel.com) wrote:
>
> > I'm okay with the change to remove gc-sections.
> >
> > systemd is pretty good at not leaving crap in its code, then results
> > are pretty small as we saw.
> >
> > My only comment is that we should also remove:
> >         -ffunction-sections
> >         -fdata-sections
> > those are only useful to enable gc-sections.
> >
> > From time to time someone should run a build with
> >         -ffunction-sections
> >         -fdata-sections
> >         -Wl,--gc-sections
> >         -Wl,--print-gc-sections
> > so we print out sections that are dangling and then we could remove
> > them from source code if needed.
>
> This is not that simple. We have a large set of shared functions in
> src/shared/*.c, and we link that into pretty much any binary we build,
> even though each binary only needs a small subset of them. We rely on
> the GC logic to deal with this and remove the functions that are
> unused by the specific program. Howver, that is not an indication that
> we can remove the function, that's simply an indication that that one
> binary of the 90 or so we build doesn't need it. Other binaries might
> need it still, but print-gc-sections won't tell you about that.

For shared libraries it won't remove exported (visible) symbols. Only
stuff (functions, variables) that have not reference are removed.

Of course those local to a file (ie: static) are always eliminated,
that's why we see minor benefit with gc-sections as the major bulk are
marked as "static". As I said, if the functions are exported
(visibility=default), then they are not GC, what leaves us to "extern"
symbols, those that are visible across files but not exported in the elf.

--
Gustavo Sverzut Barbieri
Intel Open source Technology Center


More information about the systemd-devel mailing list