Re: Stepping over longjmp presumably broken for glibc

[Daniel Jacobowitz <drow at false dot org>]

On Sat, Dec 24, 2005 at 06:36:17PM +0200, Eli Zaretskii wrote:
> > 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?

Ah.  I think there's a very important difference between the cases I
described and these: Malloc, and fork, and function calling, are all
public interfaces.  They're described by standards.  We don't need to
know anything about the particular implementation in order to use them.

But there's no standard to cover what we need here - jmp_buf's
deliberately an opaque type.

> 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.

I have less of an argument for this one, but I still do think there's a
difference.  This is a static dependence rather than a dynamic
dependence.  We can write it down, usually based on published standards
documents.

That's more true of the functional ABI than it is of the function
prologue sequences.  Which one of those two mostly works once we get it
implemented, and which one is an evolving and recurring pain that we're
contemplating entirely new approaches to? :-)  And that doesn't even
begin to handle debugging non-GCC-generated code.

The more implementation-specific knowledge we have, the less robust we
are.

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

I think that single-stepping out of longjmp will not be fragile.  It
may be hard to implement, but it should be straightforward in
principle; it's only going to be hard because of the existing mess
in infrun.c.

Anyway, that's my two cents.  I don't have time to actually implement
it right now, which is why I wanted to mention it on the mailing list;
so that either someone else will look at it, or I will find the message
again later when I can do it myself.

-- 
Daniel Jacobowitz
CodeSourcery, LLC