This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: tcbhead_t gdb access for nonthreaded, gdb for longjmp()
- From: Daniel Jacobowitz <drow at false dot org>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: libc-alpha at sourceware dot org, gdb at sourceware dot org
- Date: Sun, 10 Sep 2006 10:27:24 -0400
- Subject: Re: tcbhead_t gdb access for nonthreaded, gdb for longjmp()
- References: <20060908102235.GA31335@host0.dyn.jankratochvil.net>
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