Re: Stepping over longjmp presumably broken for glibc

[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; both are constant
sources of bugs and aggrevation.  Not so much for the native case, but
I work with a lot of people who use remote debugging, and answer many
questions about it on gdb@.

Also, as a general principle, I aim to keep the debugger as fully
isolated from the debuggee as possible.  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.

> If glibc maintainers actively fight the debugger's ability to debug
> their code, we will never succeed in catching up with them.  So I'd
> rather they stopped with that attitude and started cooperating with
> us.  I can ask RMS to try to influence the glibc team, if you think
> this will help.

I'm not sure where you're going with this.  It's not greater _human_
coordination that I'm objecting to, it's greater _machine_
coordination; version skew between glibc and gdb, support for old and
new versions, et cetera.  The hooks would not get a lot of use, and
would be very complicated - I can say the former based on the fact that
no one's noticed the problem yet (I found it by code inspection), and
the latter based on studying the implementation.  Complicated means
fragile.

I think that a solution which does not rely on support from the runtime
being debugged is inherently superior to one which does.

-- 
Daniel Jacobowitz
CodeSourcery, LLC