This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Omit frame pointer and fix %ebp by default on x86 (take3)
- From: Roger Sayle <roger at eyesopen dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Richard Henderson <rth at redhat dot com>
- Date: Thu, 19 Aug 2004 11:33:36 -0600 (MDT)
- Subject: Re: [PATCH] Omit frame pointer and fix %ebp by default on x86 (take3)
On Thu, 19 Aug 2004, Andrew Haley wrote:
> It's not a problem. libgcj.spec has this line:
>
> *jc1: -fhash-synchronization -fno-use-divide-subroutine
> -fuse-boehm-gc -fnon-call-exceptions -fno-omit-frame-pointer
> -fkeep-inline-functions
Excellent!
> My question about when we should decide to break a user-visible
> function in glibc still stands, though.
At some point in the future, some software that relies on being able
to slow down an application by misaligning the stack pointer, will also
break, once GCC starts aligning the stack on function entry. Relying
on GCC's poor code generation may not be a good long term strategy.
Although it would be possible to tweak my patch such that only non-glibc
targets, including *BSD, Darwin, VxWorks and Microsoft Windows, enjoy the
performance benefits, that seems a shame as much of the effort to allow
GCC to omit the frame pointer has been contributed by RedHat and SuSE.
I'm not sure GCC has ever claimed that it would preserve the ability
to traverse x86 stack frames using %ebp, and I'm fairly sure this
isn't a published requirement of any of the relevant (SVR4?) ABI
documents or conformance testing.
One final point that might not be obvious from my patch is that we
only omit the frame pointer when optimizing. As the user has to
explicitly specify -O, this is consistent with glibc's documented
behaviour of backtrace(3):
Note that certain compiler optimizations may interfere with
obtaining a valid backtrace.
Using "-O0" guarantees a useable backtrace (as implied above).
[Documenting -fno-omit-frame-pointer in libc/manual/debug.texi might
be a good idea though.]
Roger
--