Re: [PATCH] Omit frame pointer and fix %ebp by default on x86 (take3)

[Andrew Haley <aph at redhat dot com>]

Roger Sayle writes:
 > 
 > On Mon, 16 Aug 2004, Jakub Jelinek wrote:
 > > How is that better from making -fomit-frame-pointer
 > > -fasynchronous-unwind-tables the default.
 > 
 > Because -fasynchronous-unwind-tables results in a dramatic increase
 > in object file size.  It also only works on targets with suitable
 > debugging file formats.
 > 
 > GCC competes with the Microsoft and Intel compilers on Microsoft
 > Windows, and the arguments for asynchronous-unwind-tables and the
 > need to preserve glibc's backtrace functionality don't really hold
 > much water there.
 > 
 > It's my understanding that none of the GCC compilers themselves
 > require the functionality of backtrace, the GDB executable doesn't
 > require it, the Linux kernel doesn't require it, none of the
 > applications in the SPEC benchmark suite require it, none of
 > OpenEye's applications require it.  It's easy to list the people
 > who suffer from preserving the frame-pointer, is it only Java
 > folks that are causing this performance hold-up?

This is an interesting question.  What guarantees do we make to our
users?  

We know that this patch will disable one of the user-visible functions
in glibc.  This isn't an issue on x86_64, for example, where
backtrace() uses unwinder info.  So, we're removing functionality that
some of our customers use.  And, of course, with gcc being free
software, we don't know who all of our customers are, or what they do.

Would it not have been a good idea some time ago to convert glibc to
use unwinder info for backtrace?  Then there would have been no loss
of functionality for anyone.

With regard to Java holding up progress: I'm not going to stand in the
way.  If, for only a few weeks, we must require everything linked with
Java to be compiled with -fno-omit-frame-pointer, I can live with
that: it won't be in any released compiler, because we'll use unwinder
data in the future.  But using unwinder data for backtraces will
require libraries which make callbacks to be compiled with
-funwind-tables, and we can't always control that.  Some things will
break.

Andrew.