Re: RFC: Longjmp vs LD_POINTER_GUARD revisited

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 15 Nov 2009 12:34:29 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Pedro Alves <pedro@codesourcery.com>, 	Ulrich Weigand <uweigand@de.ibm.com>
> 
> This patch updates Pedro's work to current trunk, and adds a pragmatic
> hack.  If we recognize the name of the current function as definitely
> related to longjmp, then we know it won't return normally, so we
> should continue stepping.  For x86_64 glibc, the magic name is
> "__longjmp".  Otherwise, we do a frame check as before.

Thanks.

> +  /* The functions we set a longjmp breakpoint on.  */
> +  if (strcmp (func, "longjmp") == 0)
> +    return 1;
> +  if (strcmp (func, "_longjmp") == 0)
> +    return 1;
> +  if (strcmp (func, "siglongjmp") == 0)
> +    return 1;
> +  if (strcmp (func, "_longjmp") == 0)
> +    return 1;

Did you really mean to have _longjmp twice here?

> Index: src/gdb/NEWS
> ===================================================================
> --- src.orig/gdb/NEWS	2009-11-15 11:12:57.000000000 -0500
> +++ src/gdb/NEWS	2009-11-15 11:17:33.000000000 -0500
> @@ -3,6 +3,10 @@
>  
>  *** Changes since GDB 7.0
>  
> +* Support for stepping and nexting over longjmp has been improved.  It now
> +works independently of the architecture and supports recent versions
> +of GLIBC.
> +
>  * New targets

This part is fine.

> Index: src/gdb/doc/gdbint.texinfo
> ===================================================================
> --- src.orig/gdb/doc/gdbint.texinfo	2009-11-15 11:17:50.000000000 -0500
> +++ src/gdb/doc/gdbint.texinfo	2009-11-15 11:25:35.000000000 -0500
> @@ -609,15 +609,20 @@ stepping.  This is done with a few speci
>  which are visible in the output of the @samp{maint info breakpoint}
>  command.
>  
> -@findex gdbarch_get_longjmp_target
> -To make this work, you need to define a function called
> -@code{gdbarch_get_longjmp_target}, which will examine the
> -@code{jmp_buf} structure and extract the @code{longjmp} target address.
> -Since @code{jmp_buf} is target specific and typically defined in a
> -target header not available to @value{GDBN}, you will need to
> -determine the offset of the PC manually and return that; many targets
> -define a @code{jb_pc_offset} field in the tdep structure to save the
> -value once calculated.
> +When @value{GDBN} detects a call to @code{longjmp}, it begins
> +stepping the program.  As long as the program is still inside
> +the call to @code{longjmp} (as determined by either the current
> +function name or a stack frame search), @value{GDBN} continues
> +stepping.  Once the program has left @code{longjmp}, @value{GDBN}
> +determines whether to stop or to resume an earlier @code{next}
> +opertion.
> +
> +In many cases you do not need any architecture-specific support
> +for this feature.  You may need to augment @code{still_in_longjmp_frame_p}
> +in @file{infrun.c} to recognize any functions called by @code{longjmp}
> +which make unusual changes to the stack.  It can recognize
> +functions by name, and could recognize additional cases
> +by instruction scanning to support a stripped C library.

This is also OK, but I'd suggest to add an index entry for
still_in_longjmp_frame_p.

Thanks.