From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 682 invoked by alias); 15 Nov 2009 18:06:18 -0000 Received: (qmail 540 invoked by uid 22791); 15 Nov 2009 18:06:14 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 15 Nov 2009 18:05:10 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0KT500M00WUTZY00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Sun, 15 Nov 2009 20:05:07 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.70.37.193]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KT500JPVWWG5N90@a-mtaout22.012.net.il>; Sun, 15 Nov 2009 20:05:05 +0200 (IST) Date: Sun, 15 Nov 2009 18:06:00 -0000 From: Eli Zaretskii Subject: Re: RFC: Longjmp vs LD_POINTER_GUARD revisited In-reply-to: <20091115173429.GB23483@caradoc.them.org> To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org, pedro@codesourcery.com, uweigand@de.ibm.com Reply-to: Eli Zaretskii Message-id: <83pr7jmzos.fsf@gnu.org> References: <20091115173429.GB23483@caradoc.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-11/txt/msg00338.txt.bz2 > Date: Sun, 15 Nov 2009 12:34:29 -0500 > From: Daniel Jacobowitz > Cc: Pedro Alves , Ulrich Weigand > > 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.