================
@@ -865,7 +865,16 @@ DynamicLoaderPOSIXDYLD::GetThreadLocalData(const 
lldb::ModuleSP module_sp,
   }
 
   // Lookup the DTV structure for this thread.
-  addr_t dtv_ptr = tp + metadata.dtv_offset;
+  // On Linux AArch64, TPIDR_EL0 already points directly to struct pthread
----------------
jrtc27 wrote:

This isn't a Linux thing, this is a psABI thing. TLS Variant I architectures 
(everything other than x86, SPARC and S/390) have TP (with some offset) point 
to the TCB, which is specified (in the generic TLS spec, not a psABI) to have 
the DTV pointer at offset 0. For some architectures, TP actually points at the 
end of the TCB (sometimes with a bias to make more efficient use of immediate 
addressing modes, e.g. MIPS and PowerPC add 0x7000 so negative immediates are 
useful), i.e. the TLS data is immediately after it, and the DTV pointer is at 
`-2 * sizeof(void *)` (minus any bias). Arm and AArch64 (yes, 32-bit included) 
instead have TP point to the start of the TCB, not the end (and have no bias), 
so the DTV pointer is always at offset 0.

I don't know what struct pthread has got to do with this. You're using tp, i.e. 
GetThreadPointer()'s return value, here, not GetThreadInfo()'s return value, so 
you don't have a pointer to struct pthread (or whatever other OS-specific thing 
is returned by GetThreadInfo() on non-Linux), you have the actual TP register 
the ABI is using. This is really why it's broken; on x86 (or any other Variant 
II architecture), glibc's implementation does happen to have TP point to struct 
pthread. But on other architectures, it does not, struct pthread comes *before* 
the TCB, which is what TP is pointing to (modulo bias and start/end). So this 
"fix" is just papering over the problem that is this code only works on x86 
because it confuses TP and glibc's struct pthread pointer. It needs rewriting. 
The "FIXME(spucci): This isn't right for big-endian 64-bit" above also does not 
inspire confidence.

https://github.com/llvm/llvm-project/pull/183993
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to