This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: tcbhead_t gdb access for nonthreaded, gdb for longjmp()
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