BUG? -fomit-frame-pointer and exceptions or setjmp/longjmp

[Denis Zaitsev]

If gcc is built with the -fomit-frame-pointer in the environment's
CXXFLAGS, then we have a dead exception handling mechanics - a c++
program, compiled with such a gcc, can't catch any of an exceptions it
throws.  All the exceptions leak thru the catch (...) chain and
program finishes by kill() itself.  It's because something becomes
wrong with a thrown object's type recognition.  And the reason is the
absence of the ebp register set to a stack frame at the moment when
the exception is thrown.  The ill function here -
libsupc++/eh_throw.cc/__cxa_throw (and, very probably, __cxa_rethrow
as well).  The problem vanishes, if we recompile eh_throw.cc with
-fno-omit-frame-pointer.  But it's not the real cure.  As I
understand, FRAME_POINTER_REQUIRED must give true for such a function
(by the reason of calling _Unwind_RaiseException inside of it?), but
gcc fails to do that.

The other similar problem is with glibc/linuxthreads.  If
libpthread.so is compiled with -fomit-frame-pointer in CFLAGS, then
any threaded app finishes with SIGSEGV just after the start.  It
seems, that the problem here is in an absence of ebp correctly set
around setjmp/longjmp calls.  There are -fno-omit-frame-pointer flags
especially set for some files in the glibc/linuxthreads tree, but this
doesn't help.

I assume gcc 3.0.4, 3.1 and glibc 2.2.5.

Do I understand right, that it's a gcc's care to set up the stack
frame register when it's necessary, regardless of the
-fomit-frame-pointer flag?