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

[Pedro Alves <pedro at codesourcery dot com>]

On Wednesday 10 June 2009 18:13:28, Daniel Jacobowitz wrote:
> On Wed, Jun 10, 2009 at 06:06:31PM +0100, Pedro Alves wrote:
> > I assume that exceptions have a property that raw longjmp doesn't,
> > which is what makes stepping over longjmp complicated --- they never
> > switch to alternate stacks?  That was one reason why comparing
> > frame/stack pointers with inner_than kind of comparisions is
> > verboten (to know when the longjmp/exception is all inner to the
> > step/next and can be ignored, for example).  That, and frames
> > crossing architectures, like on Cell.  I did spot one such comparision
> > by a quick look at the patch, but I don't know if it OK to do so in
> > your case or not.  I assume other people who know more about
> > frames and unwinders than me can provide better input there.  :-)
> 
> Not sure what you mean exactly, but exceptions can be thrown through
> signal handlers on many platforms; so yes, they might switch stack.
> They could go to any stack higher on the call frame.
> 

Oh, C++ exceptions across signals, neat.  Didn't think of that.
Other than the cross-arch exceptions, I was thinking of things like using
longjmp for continuations and coroutines, and tricks like that.  There may
be clever ways to do such things with C++ exceptions, I don't know then.

Anyway, not wanting to finger-point I was refering to things like
these in the patch:

+      /* We use the current stack pointer and not the CFA here,
+        because the unwinder seems to compute the callee's CFA, and
+        so the breakpoint does not trigger.  */
+      stack_ptr = get_frame_sp (frame);

and...

+       if (!what.is_longjmp && ecs->event_thread->step_range_start
+           && (get_frame_sp (get_current_frame ())
+               == ecs->event_thread->exception_frame))
+         {


and...

+             if (!nexting_cfa
+                 || gdbarch_inner_than (arch, cfa, nexting_cfa))
+               {
+                 /* Not an interesting exception.  */
+                 break;
+               }


Which I guessed should be using frame_id comparisions, and
something other than gdbarch_inner_than, frame_find_by_id perhaps
(that does require a well behaved unwinder).  I'm not much
an expert on C++ unwinding, and haven't really studied the patch,
so I don't exactly what is being compared here.

-- 
Pedro Alves