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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

Hi,

also regarding making `__libc_version' public - it would be even useful to
check matching version of libc vs. libpthread as currently mixing various
versions has unpolite results.


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.


> But it could find the DTV directly and perform its own
> lookup, based on knowledge of the platform ABI.

(Probably described above...)


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

>   - 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'?

>   - Provide a function in ld.so to translate a link map into its TLS
>     module ID, for gdb use.

I hope you intend function callable from the gdb process; I hope it is clear
calling inferior's function (using dummy frame?) is not suitable.

...
> >  * Providing full custom TLS resolving for gdb - no glibc change needed.
> 
> I think this is what I described above.

Partially, in this case I would choose "link map" access with providing
target-dependent gdb-side link map offset (ugly, I know).


On Wed, 13 Sep 2006 15:19:48 +0200, Daniel Jacobowitz wrote:
> On Wed, Sep 13, 2006 at 03:05:32PM +0200, Jan Kratochvil wrote:
...
> > 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,

[
Sincerely thanks for pointing out my possible mistake.
Just in general - I know the differences, my patches would not work otherwise;
I know DTV, I just did not remember that acronym it is that structure before.
]



Regards,
Jan