Re: Stepping over longjmp presumably broken for glibc

Jim Blandy
2006-01-06T20:28:53Z

On 1/6/06, Daniel Jacobowitz <drow@false.org> wrote:
> On Sun, Jan 01, 2006 at 09:25:14PM -0800, Jim Blandy wrote:
> > On 12/30/05, Daniel Jacobowitz <drow@false.org> 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.