From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28320 invoked by alias); 6 Jan 2006 20:36:52 -0000 Received: (qmail 28305 invoked by uid 22791); 6 Jan 2006 20:36:51 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 06 Jan 2006 20:36:49 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EuyKI-0005Ol-GF; Fri, 06 Jan 2006 15:36:42 -0500 Date: Fri, 06 Jan 2006 20:36:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Mark Kettenis , gdb@sourceware.org Subject: Re: Stepping over longjmp presumably broken for glibc Message-ID: <20060106203642.GA20698@nevyn.them.org> Mail-Followup-To: Jim Blandy , Mark Kettenis , gdb@sourceware.org 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> <8f2776cb0601061228h50b3feaft6bf98145ef649bac@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f2776cb0601061228h50b3feaft6bf98145ef649bac@mail.gmail.com> User-Agent: Mutt/1.5.8i 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/msg00049.txt.bz2 On Fri, Jan 06, 2006 at 12:28:47PM -0800, Jim Blandy wrote: > 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. 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. -- Daniel Jacobowitz CodeSourcery