Re: RFC: next/finish/etc -vs- exceptions

[Pedro Alves <pedro at codesourcery dot com>]

On Wednesday 10 June 2009 19:29:23, Tom Tromey wrote:
> The intent is to compare the "next"ing frame with the target frame of
> the exception.  Exceptions throw up to or past the nexting frame
> should be caught be gdb.

Right, this is the bit where comparing SP or FP pointers directly
bites back (other than it is not arch portable to address SP or FP
directly).  The simplest replacement is to check if the "next"ing frame
is still in the frame chain (with frame_find_by_id).  If it is, then you
know that the target frame is inner to the "next"ing frame.  If something
goes wrong with gdb's unwinding, you'll get a false positive and just stop
the inferior in an inner frame (thus, the back case isn't runaway
process, but spurious stop).

> I don't see how this works for longjmp.  From the code it looks like
> any longjmp is caught... is that the case?

Yes, that's the case.

> I suppose the failing case for exception unwinding is if the inferior
> stops in a signal handler on a separate stack, then the user "next"s
> over a throw in that handler. ?Does that sound correct?

Yes.  Or, if you "next" in base code, and a signal (set to "pass nostop")
is caught in the meantime, the inferiors switches to an altstack, and then
the signal handler in the inferior throws.

-- 
Pedro Alves