[systemd-devel] [PATCH] build-sys: remove --gc-sections to fix debugging
Gustavo Sverzut Barbieri
gustavo.barbieri at intel.com
Thu Nov 27 10:31:04 PST 2014
On Thu, Nov 27, 2014 at 06:50:19PM +0100, David Herrmann wrote:
> Hi
>
> On Thu, Nov 27, 2014 at 6:35 PM, Peter Wu <peter at lekensteyn.nl> wrote:
> > On Thursday 27 November 2014 13:42:27 Gustavo Sverzut Barbieri wrote:
> >> 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
> >
> > OK, here is a description of the test setup such you can reproduce it.
> > Environment:
> > - Arch Linux x86_64 in a QEMU VM (live iso with systemd makedepends
> > installed).
> > - with systemd git in /tmp/systemd.
> > - master is at 9a20fcbcd1b010ad88bfbb8b7f0417bec7327fb4
> > - gcc 4.9.2
> > - binutils 2.24-8 (the broken one)
> >
> > Commands to build two versions:
> >
> > cd /tmp/systemd
> > # Currently at 9a20fcbcd1b010ad88bfbb8b7f0417bec7327fb4 + patch to
> > # remove --gc-sections and -f{data,function}-sections
> > git clean -xfd && ./autogen.sh && mkdir build && cd $_ &&
> > ../configure && make -j6 && make install DESTDIR=$PWD/fs &&
> > (cd fs && find * -type f -printf '%h/%f\t%s\n') > /tmp/0.txt
> >
> > # Now let's see what happens with --gc-sections
> > git checkout HEAD~ &&
> > git clean -xfd && ./autogen.sh && mkdir build && cd $_ &&
> > ../configure && make -j6 && make install DESTDIR=$PWD/fs &&
> > (cd fs && find * -type f -printf '%h/%f\t%s\n') > /tmp/1.txt
> >
> > Now build a table to compare the sizes:
> >
> > join {0,1}.txt | awk '$2!=$3{print $2,$3,$2-$3,$2/$3,$1}' |
> > sort -k4n | column -t > results.txt
> >
> > The columns explained:
> > 1. Size of binaries built without --gc-sections and -f...
> > 2. Size of binaries built with --gc-sections and -f...
> > 3. Absolute "saved" bytes when built with --gc-sections.
> > 4. Ratio between the sizes, numbers smaller than 1 indicate a saving,
> > numbers larger than 1 show that --gc-sections increase the sizes.
> >
> > These results are strange, it suggests that --gc-sections make the
> > binaries larger overall! I have repeated it three times just to make
> > sure that I did not made a mistake.
>
> Of course it gets bigger if every symbol is placed into it's own
> section. It's -ffunction-section and -fdata-section that make it
> bigger. But those are required for --gc-sections to work.
>
> Btw., you run with LTO, which makes --gc-sections obsolete. But we
> don't enable LTO for debug builds and I think distributions may
> disable it, too. Until we decide to rely on LTO, I'd strongly suggest
> keeping our --gc-sections + function/data-section. Either LTO _or_
> --gc-sections is required!
>
> My numbers were generated via debug-builds, which explicitly disables LTO.
>
> I'd be fine with a patch that drops --gc-sections and friends if LTO
> is enabled. But that requires us to check for LTO during ./configure
> and really make sure we know that it's enabled. So far, we just enable
> it if it's available, but never really check whether it was enabled.
Hum, then the difference makes sense. LTO :-)
Currently configure.ac has the LTO logic inside an:
AS_CASE([$CFLAGS], [*-O[[12345\ ]]*], ....
We can make the "else" block check/enable for gc-sections alongside
printing the result. See the attached (untested!) patch.
--
Gustavo Sverzut Barbieri
Intel Open source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-configure-only-use-Wl-gc-sections-if-not-using-flto.patch
Type: text/x-diff
Size: 1910 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20141127/40b9e5b2/attachment.patch>
More information about the systemd-devel
mailing list