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

Gustavo Sverzut Barbieri gustavo.barbieri at intel.com
Thu Nov 27 07:42:27 PST 2014


On Thu, Nov 27, 2014 at 03:42:37PM +0100, David Herrmann wrote:
> Hi
>
> On Wed, Nov 26, 2014 at 6:40 PM, Gustavo Sverzut Barbieri
> <gustavo.barbieri at intel.com> wrote:
> > 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.
>
> We _really_ depend on --gc-sections. We link a lot of stuff from
> src/shared/ statically into all binaries and expect the linker to drop
> any unused symbols. Note that none of the symbols from src/shared/ are
> exported, so the linker can drop them safely.
>
> I don't get why we work around linker bugs in systemd? The bug was
> fixed upstream, so make them backport it, if it's a critical bug. If
> they refuse to do so, blacklist the given version. But I dislike
> carrying fixes for other software in systemd-git.

Did you confirm what you said or is it a supposition?

I'm asking because from Peter Wu's email we're 26384 - 26380 = 4Kb
heavier in the whole installed set of binaries. If this is correct I
doubt the gc-sections is making any difference in the linkage of
static libraries (src/shared). In this case my *assumption* (as I have
no deep knowledge about the linker) is that it's selectively picking
the symbols it uses and leaving the other stuff out of it.

Peter, could you provide more in-depth information, for instance you
could see:
        - what binaries are bigger;
        - what -Wl,--gc-sections -Wl,--print-gc-section says

BR,

--
Gustavo Sverzut Barbieri
Intel Open source Technology Center


More information about the systemd-devel mailing list