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

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Sep 13, 2006 at 03:05:32PM +0200, Jan Kratochvil wrote:
> > I wonder if we really need to use libthread_db here anyway.
> 
> Besides longjmp() target PTR_DEMANGLE()ing there is also need to access glibc
> TLS symbol `errno' but - in fact - AFAIK no other TLS symbol.

You're combining two different problems here, and they're very
different.  The pointer_guard lives in the TCB, which is special
(not normal TLS data).  Normal TLS mechanisms won't work to find
it.

But the errno value lives in a standard TLS block.  All the application
needs to access it is the module number for libc.so.6 and the symbol
value.  GDB shouldn't access TLS the same way the application does
(by calling __tls_get_addr, which might e.g. cause allocation of a new
TLS block).  But it could find the DTV directly and perform its own
lookup, based on knowledge of the platform ABI.  (You mentioned earlier
not knowing what the DTV was; if that's still the case, please read
Ulrich's TLS paper, which explains it very well).

The symbol value's easily available in the symbol table.  The module
number is harder.  It's in the result from dl_iterate_phdr, which is
workable but very awkward for GDB to use.  And it's in the link_map,
but not at a public offset, so we can't find it there.

Options I see:
  - Make GDB call dl_iterate_phdr to get the module numbers.
  - Provide them in the public portion of the link map.
  - Provide a function in ld.so to translate a link map into its TLS
    module ID, for gdb use.

I'd be interested to hear from the glibc maintainers if they thought
any of those were workable.  The first is the ugliest, but most
immediately usable, since dl_iterate_phdr is already available today.

> I see multiple solutions (maybe first one enough?).
> 
>  * Hardcoding `#define errno (*__errno_location ())' into gdb.

I'd rather not be specific to errno.

>  * Providing full custom TLS resolving for gdb - no glibc change needed.

I think this is what I described above.

>  * Extending current glibc libthread_db for non-threaded inferiors.
>    (the patch sent before <20060908102235.GA31335@host0.dyn.jankratochvil.net>)

Reasonable, except that it seems like a huge patch for limited gain.

>  * Merging the basic libpthread part for TLS resolving into glibc core
>    as nonthreaded glibc is using the TLS support for threading anyway.

This could probably be made to work...

>  * Merging the whole libpthread to glibc, making libpthread just a stub,
>    forgetting there ever existed nonthreaded programs before,
>    the same way UP (vs. SMP) was forgotten.

This would work :-)

-- 
Daniel Jacobowitz
CodeSourcery