From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 625 invoked by alias); 6 Jan 2006 20:53:19 -0000 Received: (qmail 611 invoked by uid 22791); 6 Jan 2006 20:53:18 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.193) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jan 2006 20:53:15 +0000 Received: by zproxy.gmail.com with SMTP id x3so3576589nzd for ; Fri, 06 Jan 2006 12:53:13 -0800 (PST) Received: by 10.36.72.12 with SMTP id u12mr1098268nza; Fri, 06 Jan 2006 12:52:22 -0800 (PST) Received: by 10.37.2.42 with HTTP; Fri, 6 Jan 2006 12:53:12 -0800 (PST) Message-ID: <8f2776cb0601061253g252de5bfs4540cc8c340b841f@mail.gmail.com> Date: Fri, 06 Jan 2006 20:53:00 -0000 From: Jim Blandy To: Jim Blandy , Mark Kettenis , gdb@sourceware.org Subject: Re: Stepping over longjmp presumably broken for glibc In-Reply-To: <20060106203642.GA20698@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8f2776cb0512262024n39deb5e9q64ab62c48652e336@mail.gmail.com> <20051230023830.GA26004@nevyn.them.org> <200512300932.jBU9WBn6015669@elgar.sibelius.xs4all.nl> <20051230162507.GA5006@nevyn.them.org> <8f2776cb0601012125y346a1807w7dc5e5997741b4c4@mail.gmail.com> <20060106194347.GA18951@nevyn.them.org> <8f2776cb0601061228h50b3feaft6bf98145ef649bac@mail.gmail.com> <20060106203642.GA20698@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00050.txt.bz2 On 1/6/06, Daniel Jacobowitz wrote: > > The original topic of this thread was stepping through longjmp > > instruction by instruction. At some point, longjmp will inevitably > > have disturbed the state of the processor enough that you can't unwind > > back to longjmp's caller. At that point, it makes more sense for the > > 'calling' frame to be the setjmp than anything else. Until that > > point, you can have the CFI unwind to the longjmp if you prefer. > > But how can GDB reliably use this? We don't know whether the unwind > information returns to longjmp's call site or setjmp's. And we might > have to single step a bit to get to the point where it returns to the > setjmp. So as far as I'm concerned we might as well just single step > until we're out of longjmp. Sorry --- I'm losing track of the original goal here. Forget I wrote that. I think stepping through longjmp is fine. Independently, I'm excited about having groovy CFI for longjmp.