This is the mail archive of the
mailing list for the GDB project.
[RFC 0/4] - longjmp rework part 2
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Date: Wed, 9 Apr 2008 15:53:59 +0100
- Subject: [RFC 0/4] - longjmp rework part 2
This small patch series applies on top of the
previous series I sent:
[0/5 - longjmp rework]
At patch 3/5, I asked if people would agree that
when stepping, gdb should ignore longjmp's which would
land somewhere innermost to what the user is stepping.
That is, given cases like these:
if (setjmp (env) == 0) /* longjmp-resume here */
longjmp (env, 1);
hidden_longjmp (); <<<< step over this.
printf ("stop here instead\n");
Stepping over hidden_longjmp should not stop
at the "longjmp-resume here" mark, but instead,
if the step should proceed to the next line and
stop in the printf.
Tom's opinion expresses exactly what I believe should
A Monday 07 April 2008 16:28:06, Tom Tromey wrote:
> >>>>> "Pedro" == Pedro Alves <email@example.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.
So, here are the patches that apply on top of the other series to get this
I fully tested them on:
- i686-pc-linux-gnu (with the pointer unmangling patch)
- x86_64-unknown-linux-gnu (with the pointer unmangling patch)
And tested just the new longjmp.exp tests on:
Patches on this series are:
[RFC 1/4] - Only longjmp if going outer.
[RFC 2/4] - Update tests
[RFC 3/4] - Adjust all archs/targets to new interface
[RFC 4/4] - Adjust x86 and x86_64 linux.