Re: 3/5 - Rework stepping over longjmp support

[Tom Tromey <tromey@redhat.com>]

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

Pedro> The longjmp inside hidden_longjmp is going to land inside
Pedro> hidden_longjmp.  GDB could ignore it leave the step-resume
Pedro> breakpoint at the return of hidden_longjmp and pretend
Pedro> that longjmp was never seen.  Think of stepping over a function
Pedro> in gdb's sources, and an exception being thrown and caught all
Pedro> somewhere inner to the function you're stepping.  I've
Pedro> implemented a prototype patch that does this.  Does anyone
Pedro> else think that behaviour is useful?

I do.  Speaking as a user, this is the behavior I expect.  That is, if
I 'next' over a function call (and assuming the "easy" case -- no user
breakpoints or watchpoints or the like), anything that happens during
that function call should be invisible to me.  And, in my view, the
inferior should stop at the "next" instruction after the function
call; if that is in an outer frame, then I want to stop there.

Ideally, of course, all this should happen for exceptions in c++ and
java as well :-).  FWIW the c++ case is more important to me ... but
I'm rather fascinated by this patch series because I didn't know this
code even existed, and it makes handling exceptions seem more
possible.

Pedro> (I'm aware that any
Pedro> smartness we add can be defeated by longjmp changing stacks,
Pedro> or stuff like debugging coroutines implemented with set/longjmp,
Pedro> but those feel like rare enough that a smart mode could be
Pedro> the default and useful most of (almost-all) the times.)

As long as folks doing unusual stuff like this can cope for
themselves, I think your proposed behavior is preferable.

Tom