[busybox] some size savings
rep.nop at aon.at
Mon Oct 10 18:51:28 UTC 2005
[changing the subject to something more appropriate]
Recap: Size savings "for free" i.e. without touching individual applets
but improving the way busybox is built. For free in quotes as someone
still has to do the grunt "work". Work in quotes as it's Just For Fun
and cleanliness, at least for my part.
On Sun, Oct 09, 2005 at 08:16:12PM +0200, Bernhard Fischer wrote:
>On Sat, Oct 08, 2005 at 04:14:34PM -0500, Rob Landley wrote:
>>On Saturday 08 October 2005 08:38, Bernhard Fischer wrote:
>>> >I'll look into building libbb in one go now..
>>> Looks promising. There is most likely still opportunity for the compiler
>>> to optimize, but for a start (without any fancy tricks) it looks ok:
>>That is a _nice_ size savings.
>Here are numbers after having converted all internal libs to this.
>It's expected that switching only the libs doesn't make much of a
>difference. The majority of the code-size is added by the applets
>which aren't (yet, should we?) converted.
ping. Should we (i.e. /me) do that?
It would take some time to convert these, so i won't start to look into
it if somebody is strictly opposed to it.
>Results for allyesconfig, non-static without using libbusybox.so.
>Binaries were built with the same toolchain, oorig is current trunk,
>the other one is with the patch mentioned below.
>$ ls -sn ../busybox.oorig/busybox busybox
> 896 -rwxr-xr-x 1 0 0 913224 2005-10-09 19:47 busybox
>1076 -rwxr-xr-x 1 0 0 1097653 2005-10-09 18:54 ../busybox.oorig/busybox
>$ size ../busybox.oorig/busybox busybox
> text data bss dec hex filename
> 897847 15760 1072772 1986379 1e4f4b ../busybox.oorig/busybox
> 895878 15832 1070068 1981778 1e3d52 busybox
intriguing, isn't it? :)
>>I think this can still go into 1.1, as can the libbb.so patch. Just because
>>I'm pushing for a -pre1 doesn't mean we'll be shipping 1.1.0 before january.
>Ok. I'd be glad if somebody can verify that the patch is ok for other
>setups than gcc-4.x and glibc 2.3.5-6 on an i386.. I *think* the
>majority is ok, except the ldflags for the .so (should be weeded out and
>Please note that there is some cruft left, so it has to be cleaned up a
>bit before it can go in.
All XXX has to be revisited.
Also, i need to know if folks want to be able to build the individual .o
E.g. for size-optimisations, should
rm -f libbb/bb_echo.o;make $(pwd)/libbb/bb_echo.o
still produce bb_echo.o or not? I could ditch the rules to build
individual objects if only the overall size is interresting. Note that
imho the overall size needed does count in the end, still i see that it
is useful to allow for optimizing single obj. Opinions?
The patch is around 30k uncompressed, so i'm hesitating to send it to
the list. I can of course change my mind if people think that muxing
stuff like that is more welcome....
>Anyway. Updated patch is here:
>$ diffstat ./busybox.libs.03b.diff
> Makefile | 49 ++++++++
> README | 6 -
> Rules.mak | 16 ++
> applets/install.sh | 13 ++
> archival/libunarchive/Makefile.in | 42 +++----
> coreutils/libcoreutils/Makefile.in | 49 +++++---
> coreutils/uniq.c | 16 --
> libbb/Makefile.in | 206 ++++++++++++++++++++++++++-----------
> libpwdgrp/Makefile.in | 28 +++--
> networking/libiproute/Makefile.in | 38 +++---
> sysdeps/linux/Config.in | 23 +++-
> 11 files changed, 333 insertions(+), 153 deletions(-)
More information about the busybox