From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28175 invoked by alias); 6 Jan 2006 21:27:44 -0000 Received: (qmail 28166 invoked by uid 22791); 6 Jan 2006 21:27:43 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jan 2006 21:27:42 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k06LQTJZ007344; Fri, 6 Jan 2006 22:26:29 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id k06LQTgN009460; Fri, 6 Jan 2006 22:26:29 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id k06LQT8Y012488; Fri, 6 Jan 2006 22:26:29 +0100 (CET) Date: Fri, 06 Jan 2006 21:27:00 -0000 Message-Id: <200601062126.k06LQT8Y012488@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: jimb@red-bean.com, gdb@sourceware.org In-reply-to: <20060106203642.GA20698@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 6 Jan 2006 15:36:42 -0500) Subject: Re: Stepping over longjmp presumably broken for glibc 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> <20060106203642.GA20698@nevyn.them.org> 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/msg00051.txt.bz2 > X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on > elgar.sibelius.xs4all.nl > X-Spam-Level: > X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=no > version=3.1.0 > Date: Fri, 6 Jan 2006 15:36:42 -0500 > From: Daniel Jacobowitz > Cc: Mark Kettenis , gdb@sourceware.org > Mail-Followup-To: Jim Blandy , > Mark Kettenis , gdb@sourceware.org > Content-Disposition: inline > X-XS4ALL-DNSBL-Checked: mxdrop28.xs4all.nl checked 66.93.172.17 against DNS blacklists > X-Virus-Scanned: by XS4ALL Virus Scanner > X-XS4ALL-Spam-Score: 0 () > X-XS4ALL-Spam: NO > Envelope-To: mark.kettenis@xs4all.nl > X-UIDL: 1136579810._smtp.mxdrop28.60854,S=3285 > > On Fri, Jan 06, 2006 at 12:28:47PM -0800, Jim Blandy 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. But we can check whether it returns to setjmp or not. Mark