[PATCH] PR 16373: -fomit-frame-pointer when optimizing on x86

Roger Sayle roger@eyesopen.com
Sat Jul 17 00:41:00 GMT 2004


On Fri, 16 Jul 2004, Zack Weinberg wrote:
> What was wrong with making -fomit-frame-pointer imply
> -fasynchronous-unwind-tables?

This is something that perhaps someone can clear up for me.  Adding
-fasynchronous-unwind-tables to GCC doesn't appear to fix glibc's
backtrace(3) function (which reserving %ebp would).  Clearly there's
some context that needs to be explained to me, probably "gdb"?, that
explains why/how -fasynchronous-unwind-tables addresses/resolves an
issue that's currently blocking -fomit-frame-pointer by default.

I can understand why backtrace(3) causes a problem, but I'm still
unsure about -fasynchronous-unwind-tables; for example why this has
any more benefit than -funwind-tables.  If "backtrace" can't be used
through signal frames, then perhaps a compromise might be to add a
new -ftrapping-unwind-tables?  And if its only a "gdb" issue, maybe
the solution need only be restricted to "-g".


> People concerned with code size can turn it back off again.

It's a correctness issue.  I've been told ommitting the frame pointer
without asynchronous unwind tables is unsafe, and therefore inappropriate
for -Os.  A better alternative would be to have -Os require a frame
pointer and thereby omit the unwind tables, as the resulting binary
object files (as measured by CSiBE) would be smaller.

Of course, if someone had recently proposed a method for "safely"
ommitting the frame pointer, independently of DWARF-2 annotations,
that would still be the best solution :>

Confused of Santa Fe
--



More information about the Gcc-patches mailing list