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

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Sep 13, 2006 at 08:37:05PM +0200, Jan Kratochvil wrote:
> On Wed, 13 Sep 2006 15:19:48 +0200, Daniel Jacobowitz wrote:
> ...
> > 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).
> 
> glibc nptl_db already accesses inferior TLS IMO in a safe unmodifying way.
> Everything through td_thr_tls_get_addr() ...
> Without libthread_db support the TLS base can be queried by
> ps_get_thread_area(), using read_register() etc., done in the patch for TCB
> `pointer_guard'. Accessing DTV fields is just some indirection, the problem
> is mapping the module address to module id as you describe below.

I think you've missed my point here: we can get at errno in a single
threaded program by bypassing libthread_db.  The DTV is not an
indirection; td_thr_tls_get_addr is an abstraction on top of direct DTV
access.

> > 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.
> 
> It would be needed to be called remotely in the inferior process, wouldn't be?

Yes.  This isn't hard.

> >   - Provide them in the public portion of the link map.
> 
> `libpthread.so' already contains public `_thread_db_link_map_l_tls_modid',
> doesn't it just mean moving (or appropriately providing) this public symbol
> from `libpthread.so' to `libc.so'?

Well, right now that's only for thread_db usage.  I hadn't thought
about it, but we could use it directly from GDB; I guess that would
work fine.  We could move those thread-db related symbols which
provide information about libc (not libpthread) data structures to
libc.so and look them up directly.

I'm not sure how this would work with static linking however.  Being
able to do whatever we do for dynamic apps for static ones also would
be desirable.

Also, distributions generally strip symbols from libc.so; we'll have to
let them know to give it the same special treatment they already give
libpthread.so.

-- 
Daniel Jacobowitz
CodeSourcery