From: "Kris Warkentin" <kewarken@qnx.com>
To: "Michael Snyder" <msnyder@redhat.com>, "Nick Clifton" <nickc@redhat.com>
Cc: <gdb-patches@sources.redhat.com>, <binutils@sources.redhat.com>
Subject: Re: RFC: strip --strip-nondebug
Date: Thu, 05 Jun 2003 19:54:00 -0000 [thread overview]
Message-ID: <04dc01c32b9c$48a0b4d0$0202040a@catdog> (raw)
In-Reply-To: <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
prev parent reply other threads:[~2003-06-05 19:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-05 15:57 Nick Clifton
2003-06-05 16:06 ` Ian Lance Taylor
2003-06-05 16:24 ` Daniel Jacobowitz
2003-06-05 16:14 ` Andrew Cagney
2003-06-05 16:24 ` Elena Zannoni
2003-06-05 17:08 ` Nick Clifton
2003-06-05 19:19 ` Elena Zannoni
2003-06-06 11:17 ` Nick Clifton
2003-06-06 13:11 ` Elena Zannoni
2003-06-06 14:32 ` Nick Clifton
2003-06-06 14:51 ` Nick Clifton
2003-06-06 21:34 ` Andrew Cagney
2003-06-07 10:39 ` Nick Clifton
2003-06-07 15:37 ` Andrew Cagney
2003-06-05 18:29 ` Michael Snyder
2003-06-05 18:48 ` Daniel Jacobowitz
2003-06-05 19:06 ` Michael Snyder
2003-06-05 19:13 ` Elena Zannoni
2003-06-05 19:47 ` Nick Clifton
2003-06-05 19:54 ` Kris Warkentin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='04dc01c32b9c$48a0b4d0$0202040a@catdog' \
--to=kewarken@qnx.com \
--cc=binutils@sources.redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=msnyder@redhat.com \
--cc=nickc@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox