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

Pedro Alves
2009-06-10T17:47:06Z

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