Re: [Valgrind-developers] fomit-frame-pointer residuals

[Florian K. <br...@ac...>]

On 05/21/2012 04:51 PM, Julian Seward wrote:

> The rationale is:
> 
>   mc_main.c contains the expensive bit of Memcheck (the helper functions
>   that get called millions of times per second).  On x86 it's important
>   to build this with -fomit-frame-pointer so as to maximise performance.
> 
>   mc_replace_strmem.c runs on the simulated CPU, and it often appears
>   in stack traces shown to the user.  It is built with
>   -fno-omit-frame-pointer so as to guarantee robust backtraces on x86,
>   on which CFI based unwinding is not the "normal" case and so is
>   sometimes fragile.
> 
>> Removing those did not make a difference on amd64, ppc, and s390x.
>> Any objections to removing those?
> 
> I'd like to preserve these settings.  IIUC, recent changes to
> Makefile.all.am (??) cause mc_main.c to be built -fomit-frame-pointer
> on all platforms anyway (is that correct?  

No, only x86, amd64, and s390x have -fomit-frame-pointer universally
enabled. When we discussed this on IRC, you weren't sure whether it was
the right thing to do for ppc. Also, ARM does not have
-fomit-frame-pointer enabled.

> I didn't follow all the
> details of the discussion on it).  So that can be rm'd.

Not quite, I guess.

> 
> -fno-omit-frame-pointer for mc_replace_strmem.c, I'd like to
> preserve, for the reason above.
> 

Yeah makes sense. I presume you won't object if I add your explanation
as a comment in the Makefile :)

> It's easier to make sense of this stuff when experimenting with x86,
> since that's the one platform on which -fomit-frame-pointer does make
> a sometimes dramatic difference (between stack traces and no stack traces).

I used to have access to an x86 but no more...

   Florian