* Jan Kratochvil:
> On Tue, 14 May 2019 13:38:57 +0200, Florian Weimer via lldb-dev wrote:
>> The target process has loaded libpthread.so.0, so it's not the usual
>> problem of libthread_db not working without libpthread.
>>
>> On the other hand, I realize now that the lldb command cannot access TLS
>> variables, either. Is this expected to work at all?
>
> TLS is implemented only for FreeBSD as there is
> FreeBSDThread::GetThreadPointer() but on Linux it falls back to unimplemented:
> lldb::addr_t Thread::GetThreadPointer() { return LLDB_INVALID_ADDRESS; }
>
> On Linux it uses DynamicLoaderPOSIXDYLD::GetThreadLocalData() which may work
> without libthread_db as it is reading "_thread_db_*" symbols in
> DYLDRendezvous::GetThreadInfo(). But it needs that GetThreadPointer() which
> could get implemented (for x86_64) by reading %fs_base. LLDB currently does
> not know anything about %fs_base+%gs_base.
>
If I can get the TLS base address on x86 for a thread and if LLDB can
expose the offset of an initial-exec TLS variable inside the TLS block
of an object (which should be encoded in the ELF data), I can poke at
glibc internals and figure out the offset from thread pointer.
(Global-dynamic TLS is much more difficult to handle, of course.)
> Is it a good idea to implement %fs_base+%gs_base to make TLS working
> on Linux?
The register access would help, I think. Even if the rest doesn't work.
If you have an experimental build, I can try it.
Thanks,
Florian
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
