This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR 16373: -fomit-frame-pointer when optimizing on x86
On Mon, Jul 12, 2004 at 12:45:05AM -0600, Roger Sayle wrote:
> > I don't think we can turn -fomit-frame-pointer by default on unless
> > we also -fasynchronous-unwind-tables, because otherwise things like
> > glibc's backtrace(3) has zero chance of ever working.
>
> I doubt that this would be acceptable. Could you confirm that glibc's
> backtrace(3) command only requires -fasynchronous-unwind-tables to
> handle "asynchronous" events, such as interrupts and pre-emption, rather
> than being necessary for regular code? I notice that by default the
> x86 Linux kernel is compiled with -fomit-frame-pointer but without
> -fasynchronous-unwind-tables. Similarly how's this handled by other
It increases read-only data, and as long as .eh_frame/.eh_frame_hdr
sections are never used by the application, because
.eh_frame/.eh_frame_hdr/.gcc_except_table sections are located these days
at the end of the read-only ELF segment, the size impact is either zero,
or at most a partial 4KB page.
> targets that define CAN_DEBUG_WITHOUT_FP including the alpha, arm, avr,
> fr30, frv, ia64, hq2000, m32r, mps, mmix, mn10300, pa, rs6000, s390,
> sparc, stormy16, v850 and xtensa.
E.g. ia64 emits its format of unwind data unconditionally, sparc has
essentially frame pointer always present unless in leaf function (due to
register windows), s390* has -fasynchronous-unwind-tables by default,
various other arches have fixed conventions how to do the backtrace even
without frame pointer (storing a backchain on the stack, etc.).
Jakub