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

[Daniel Berlin <dberlin at dberlin dot org>]

On Tue, 18 Jun 2002, Denis Zaitsev wrote:

> On Fri, Jun 14, 2002 at 08:00:12PM +0100, Nix wrote:
> > On Fri, 14 Jun 2002, Denis Zaitsev said:
> > > On Mon, Jun 10, 2002 at 09:48:28PM +0100, Nix wrote:
> > >> ...
> > >> As the trace shows, this crash occurs during unwinding, the presence or
> > >> absence of a catch is irrelevant. I'm rather wondering why we're hitting
> > >> MD_FALLBACK_FRAME_STATE_FOR at all: perhaps there's a problem in FDE
> > >> generation or something.
> > > 
> > > Exact, uw_update_context_1 calculates bad context->cfa, if it works
> > > for a function with the frame pointer omited.  Now I'm looking what
> > > follows...
> > 
> > Ah, so it was `working' beforehand only because the fallback function
> > was recovering from the FDE unwinder's[1] errors?
> 
> No, it seems that it's because of ebp set - this saves us from a bad
> DWARF info...
> 
> readelf shows that DWARF's encoding of the CFA is very broken.  It is
> not broken for only a few first pushes a function does.  And if that
> function is compiled with the frame pointer not omited, that this
> frame pointer will be set thru these first steps.  After that DWARF
> info refers for it in the CFA description.  So, we have the CFA ok
> despite of the wrong DWARF info about the rest of the function.
> 
> But we catch all the bad things, if the function is compiled with the
> frame pointer omited.  That way the CFA is described thru the stack
> pointer register.  It really drifts thru the function's flow, but the
> DWARF info is not describing this drift correctly.  So, this way we
> can't avoid the broken DWARF stuff.
> 
> BTW, it seems that many GDB problems which are discussed in this list
> have the same origin, but I can't affirm...
I sincerely doubt it, since only x86-64 reads or uses the frame info.

> 
>