This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 5/5 - handle glibc pointer mangling jmp_bufs (x86/x86_64)


A Tuesday 15 April 2008 13:31:03, Daniel Jacobowitz wrote:
> On Mon, Apr 14, 2008 at 03:30:49PM -0400, Daniel Jacobowitz wrote:
> > You could do this even more evilly.  Do it by setting a breakpoint on
> > setjmp, recording information before and after, and then deleting the
> > breakpoint until we re-run.  Yes, this is getting excessive.  But
> > there shouldn't ever be a call to longjmp without a call to setjmp
> > first.
>
> Thinking about this more, how hard would it be to single-step through
> longjmp instead?  

That's how I used to do it manually whenever I wanted to step through
a gdb `error' call (it works on x86_64-unknown-linux-gnu at least), and
that's what I believe the ecs->handling_longjmp writer was trying to
achieve (someday when it would be finished).

If should be doable, but will take more work.  you want to step
until you get to an outer frame than the longjmp frame -- you may have
to go through siglongjmp etc.  infrun.c isn't ready to handle that,
as it stops stepping whenever you enter a new frame.

> I'm sure there will be some platform where it 
> doesn't work, and that platform can use the current get_longjmp_target
> mechanism, but for glibc platforms we could just step and see where we
> end up, then decide whether to continue or stop.

Not sure what's easier, but should be doable as well, if the platform
enables stepping all the way through.

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]