[RFC 0/4] - longjmp rework part 2

Pedro Alves pedro@codesourcery.com
Wed Apr 9 14:56:00 GMT 2008


This small patch series applies on top of the
previous series I sent:

[0/5 - longjmp rework]
http://sourceware.org/ml/gdb-patches/2008-04/msg00122.html

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:

 void
 hidden_longjmp (void)
 {
   if (setjmp (env) == 0) /* longjmp-resume here */
     {
       longjmp (env, 1);
     }
   else
     {
       printf ("resumed\n");
     }
 }
 
 int
 main ()
 {
    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
happen too:

A Monday 07 April 2008 16:28:06, Tom Tromey wrote:
> >>>>> "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.
>

So, here are the patches that apply on top of the other series to get this
behaviour.

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:
- arm-unknown-linux-gnueabi
- mips-linux-gnu
- i686-pc-cygwin

Patches on this series are:

 [RFC 1/4] - Only longjmp if going outer.
       longjmp_rewrite_outer.diff

 [RFC 2/4] - Update tests
       longjmp_tests_outer.diff

 [RFC 3/4] - Adjust all archs/targets to new interface
       longjmp_adjust_all.diff

 [RFC 4/4] - Adjust x86 and x86_64 linux.
       longjmp_adjust_pointer_demangle.diff

-- 
Pedro Alves



More information about the Gdb-patches mailing list