This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [Valgrind-developers] Memcheck optimisation level; Makefile.amincludes
- From: Andrew Haley <aph at redhat dot com>
- To: Nicholas Nethercote <njn25 at cam dot ac dot uk>
- Cc: Florian Weimer <fw at deneb dot enyo dot de>, Julian Seward <jseward at acm dot org>, Valgrind Developers <valgrind-developers at lists dot sourceforge dot net>, gcc at gcc dot gnu dot org
- Date: Wed, 25 Aug 2004 11:34:33 +0100
- Subject: Re: [Valgrind-developers] Memcheck optimisation level; Makefile.amincludes
- References: <Pine.LNX.4.60.0408241209100.28550@hermes-1.csi.cam.ac.uk><1093388744.4449.15.camel@localhost><1093410677.3058.29.camel@camp4.serpentine.com><200408250920.24024.jseward@acm.org><Pine.LNX.4.60.0408251012491.8646@hermes-1.csi.cam.ac.uk><87brgzo82p.fsf@deneb.enyo.de><Pine.LNX.4.60.0408251104150.8646@hermes-1.csi.cam.ac.uk>
Nicholas Nethercote writes:
> On Wed, 25 Aug 2004, Florian Weimer wrote:
>
> >> So why are the total file sizes larger with -fomit-frame-pointer?
> >
> > Have you already ruled out debugging information? Since you compile
> > with -g, this seems the most likely culprit. (If there is not frame
> > pointer, more debugging information is needed to access local
> > variables, so this growth isn't really avoidable.)
>
> Ah, I didn't think of that, I think it answers the question... for
> vgskin_lackey.so, I get the following sizes:
>
> normal: 26577
> -fomit-fp: 27299
>
> normal stripped: 7780
> -fomit-fp stripped: 7748
>
> The stripped versions look as expected, ie. with -fomit-fp it is smaller.
> It's interesting to see this effect, and good to know why it occurs.
Here you are:
/tmp/vgskin_lackey.so-normal
27 .debug_frame 00000144 00000000 00000000 0000418c 2**2
CONTENTS, READONLY, DEBUGGING
/tmp/vgskin_lackey.so-fomitfp
27 .debug_frame 000003f8 00000000 00000000 00004164 2**2
CONTENTS, READONLY, DEBUGGING