Re: Stepping over longjmp presumably broken for glibc

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 24 Dec 2005 11:23:02 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Fri, Dec 23, 2005 at 07:46:09PM +0200, Eli Zaretskii wrote:
> > > Date: Fri, 23 Dec 2005 12:09:13 -0500
> > > From: Daniel Jacobowitz <drow@false.org>
> > > 
> > > with the added downside of greater coordination between the
> > > debugger and runtime (additional points of failure).
> > 
> > We already have this downside (in many parts of GDB, not only in this
> > particular situation), so continuing with that won't be a change for
> > the worse.
> 
> Sorry, but I think it will.  The only two places that come to mind for
> glibc are the shared library list and libthread_db

What about the symbols we use when we look for specific functions,
like malloc and fork?

I also don't see any significant difference between dependencies on
intimate details of the runtime library and the details of the ABI,
like function prologue emitted by GCC.  We depend on that in lots of
places.

> Also, as a general principle, I aim to keep the debugger as fully
> isolated from the debuggee as possible.

I agree in principle, but given that we already depend on that, is
there any reason to resist in this single case?

  I spend a lot of time
> debugging the C runtime, and the bits where GDB tries to "cooperate"
> with it are extremely frustrating in that case.  When I have some more
> time for it, I'll be further reducing our dependence on glibc for
> threads.
> 
> I think that a solution which does not rely on support from the runtime
> being debugged is inherently superior to one which does.

If we can find one, and if it is not fragile, then I agree 110%.