From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24030 invoked by alias); 6 Jan 2006 20:28:53 -0000 Received: (qmail 23844 invoked by uid 22791); 6 Jan 2006 20:28:52 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.202) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jan 2006 20:28:50 +0000 Received: by zproxy.gmail.com with SMTP id x3so3572550nzd for ; Fri, 06 Jan 2006 12:28:48 -0800 (PST) Received: by 10.37.12.25 with SMTP id p25mr8674510nzi; Fri, 06 Jan 2006 12:28:48 -0800 (PST) Received: by 10.37.2.42 with HTTP; Fri, 6 Jan 2006 12:28:47 -0800 (PST) Message-ID: <8f2776cb0601061228h50b3feaft6bf98145ef649bac@mail.gmail.com> Date: Fri, 06 Jan 2006 20:28: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: <20060106194347.GA18951@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8f2776cb0512252006i4b28abe7if0fd67dd8cee6f10@mail.gmail.com> <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> 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/msg00048.txt.bz2 On 1/6/06, Daniel Jacobowitz wrote: > On Sun, Jan 01, 2006 at 09:25:14PM -0800, Jim Blandy wrote: > > On 12/30/05, Daniel Jacobowitz wrote: > > > That's not what I meant - I meant between a longjmp with "normal" > > > unwind information, or with Jim's proposed "magic" unwind information > > > that returned to the setjmp target. There's got to be at least one of > > > the former out there somewhere... > > > > Why do you need to? If I'm thinking this through right, once longjmp > > is annotated this way, GDB has no further work to do. The bug is > > "fixed", just not in GDB. > > I don't know about you, but I'd be pretty disturbed if "break longjmp; > continue; backtrace; up; list" showed me a setjmp instead of a longjmp. 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.