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

[Tom Tromey <tromey@redhat.com>]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> Oh, C++ exceptions across signals, neat.  Didn't think of that.

Does that work if you specify a signal stack?
I don't know.

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

I don't think so.  But I am prepared to be surprised.

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

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

This is bogus, btw, because for the comparison to work properly we
must compute the Dwarf CFA.  There's currently no way that I know of
to do this, so presumably some kind of extension to the frame API will
be needed.

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

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

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.

I don't see how this works for longjmp.  From the code it looks like
any longjmp is caught... is that the case?  I assume I'm missing
something, would you mind point it out?

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?

Thanks for the hint about frame_id comparisons.  I will look into
that.

Tom