This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: Longjmp vs LD_POINTER_GUARD revisited
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb-patches at sourceware dot org, pedro at codesourcery dot com, uweigand at de dot ibm dot com
- Date: Sun, 15 Nov 2009 20:05:07 +0200
- Subject: Re: RFC: Longjmp vs LD_POINTER_GUARD revisited
- References: <20091115173429.GB23483@caradoc.them.org>
- Reply-to: Eli Zaretskii <eliz at gnu dot 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.