This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: RFC: strip --strip-nondebug
- From: "Kris Warkentin" <kewarken at qnx dot com>
- To: "Michael Snyder" <msnyder at redhat dot com>, "Nick Clifton" <nickc at redhat dot com>
- Cc: <gdb-patches at sources dot redhat dot com>, <binutils at sources dot redhat dot com>
- Date: Thu, 5 Jun 2003 15:54:32 -0400
- Subject: Re: RFC: strip --strip-nondebug
- References: <m34r34a590.fsf@redhat.com> <3EDF8C1C.5D5067DE@redhat.com> <m3n0gw71gd.fsf@redhat.com>
> > How big a reduction in size would you expect, typically?
> > I'm a little ignorant, but what strippable info is in there
> > that gdb doesn't need?
>
> Quite a lot it would seem. I have not done any rigorous studies but I
> did try out a simple hello world program:
>
> compiled hello executable: 11999 bytes
> after strip --strip-debug: 4350 bytes
> after strip --strip-all: 2772 bytes
> after strip --strip-nondebug 6725 bytes
>
> So even taking a debug stripped executable and its associated debug
> file, the combined size is 4350 + 6725 = 11075 which is less than the
> original.
We do something like this for remote debugging. The target doesn't need the
debug info so we strip it before we send it off. GDB on the host reads the
original binary and the target runs the stripped one.
> Of course the patch does not work properly yet. (GDB does not seem to
> find/understand the debug info file) so the sizes will probably
> change). But in the normal case of running an program, having an
> executable that is significantly smaller must surely result in some
> performance benefits.
Actually, I wouldn't expect so. None of the debug stuff is loadable anyway.
But that's okay: space is an adequate optimization even if time is the more
fashionable one these days. Hard drives and ram are practically free but
embedded boards are almost always short on resources and flash isn't quite
as cheap.
cheers,
Kris