Re: Stepping over longjmp presumably broken for glibc

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> 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 <drow@false.org>
> Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, gdb@sourceware.org
> Mail-Followup-To: Jim Blandy <jimb@red-bean.com>,
> 	Mark Kettenis <mark.kettenis@xs4all.nl>, 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