This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Stepping over longjmp presumably broken for glibc
On Fri, Jan 06, 2006 at 12:28:47PM -0800, Jim Blandy wrote:
> 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.
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