[lldb-dev] Access to TLS variables on GNU/Linux

Florian Weimer via lldb-dev lldb-dev at lists.llvm.org
Thu May 16 00:09:00 PDT 2019

* 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.


More information about the lldb-dev mailing list