From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14772 invoked by alias); 5 Jun 2003 19:54:12 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14652 invoked from network); 5 Jun 2003 19:54:12 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 5 Jun 2003 19:54:12 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3p2/8.9.3) with ESMTP id PAA17806; Thu, 5 Jun 2003 15:48:40 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id PAA15436; Thu, 5 Jun 2003 15:54:10 -0400 Message-ID: <04dc01c32b9c$48a0b4d0$0202040a@catdog> From: "Kris Warkentin" To: "Michael Snyder" , "Nick Clifton" Cc: , References: <3EDF8C1C.5D5067DE@redhat.com> Subject: Re: RFC: strip --strip-nondebug Date: Thu, 05 Jun 2003 19:54:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SW-Source: 2003-06/txt/msg00219.txt.bz2 > > 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