Re: tcbhead_t gdb access for nonthreaded, gdb for longjmp()

[Daniel Jacobowitz <drow@false.org>]

Hi Jan, thanks for working on this.

On Fri, Sep 08, 2006 at 12:22:35PM +0200, Jan Kratochvil wrote:
> glibc part:
> 
>  * Provide some access to the `tcbhead_t.pointer_guard' field for gdb.
>    Currently implemented by `td_thr_getxregs' providing only `pointer_guard'.
>    New non-Solaris `td_thr_*' function could be provided instead.
> 
>  * All the `libthread_db' functions accessing inferior's `_thread_db*' symbols
>    of `libpthread' fallback to the new `_local_db*' symbols in `libthread_db'
>    itself. `libthread_db'<=>`libpthread' versions must match anyway.
>    I admit I do not know how may `libthread_db' and `libpthread' as there is
>    already required in `td_ta_new' their versions match.  Anyway it should be
>    enough for 99% of cases - as the fallback option.

Your new libthread_db will accept any version of glibc, even one which
does not match - that seems like a good way to get in a lot of trouble.

I wonder if we really need to use libthread_db here anyway.  The
original goal of libthread_db, as I understand it, was to abstract away
the internals of the threading library from its higher level concepts;
for instance, you weren't supposed to have to know how to map threads
to LWPs, or how to find the locks owned by a thread (on Solaris's,
glibc's doesn't implement that).  This is a C library internal, with
not much to do with threads except that most platforms happen to use a
TLS address.

We're interested in "is there a pointer guard" and "is it used for
the PC value in setjmp/longjmp".  We need both pieces of information,
because some targets do and some don't; ia64 only encrypts rp, for
instance, not sp or pc.  We could provide those two bits of constant
information in libc somewhere.

Alternatively, since I don't see anything else in glibc that mangles
pointers which GDB would need to know about (except maybe atexit
functions, which might be nice to display someday?) we could provide
a function in glibc which we could call that would return the target
of a jmp_buf.  Then GDB wouldn't have to know how PTR_MANGLE worked.

Glibc maintainers, does that last idea sound practical?  It's much
simpler.  It'll take up a dozen or so bytes at runtime, hopefully not
paged in depending where they're linked.


-- 
Daniel Jacobowitz
CodeSourcery