[Lldb-commits] [lldb] [lldb][RISCV] Implement access to TLS variables on RISC-V (PR #191410)

[Georgiy Samoylov via lldb-commits]

================
@@ -915,8 +950,26 @@ DynamicLoaderPOSIXDYLD::GetThreadLocalData(const lldb::ModuleSP module_sp,
   if (tls_block == LLDB_INVALID_ADDRESS) {
     LLDB_LOGF(log, "GetThreadLocalData error: fail to read tls_block");
     return LLDB_INVALID_ADDRESS;
-  } else
-    return tls_block + tls_file_addr;
+  }
+
+  // DW_OP_GNU_push_tls_address gives us a value in tls_file_addr that can be
----------------
sga-sc wrote:

You’re right that what I’m describing for RISC‑V/glibc is not the “pure offset” case that `DW_OP_GNU_push_tls_address` was originally intended to cover in that document. In my test binaries clang/LLVM is emitting:

* on x86_64: `DW_OP_const8u <offset>, DW_OP_GNU_push_tls_address` — here the operand really is a TPOFF‑style offset inside the TLS block;

* on RISC‑V: `DW_OP_const8u <PT_TLS.p_vaddr + tpoff>, DW_OP_GNU_push_tls_address` — effectively a VMA in the TLS segment, which then needs to be normalized back to an offset before combining with the DTV‑based `tls_block`.

So I agree this doesn’t strictly match the “offset in TLS area” wording from the elfutils doc, and it might be arguable that the RISC‑V producer is stretching the original intent of `DW_OP_GNU_push_tls_address` here.

Given that this encoding is what current clang/LLVM produces today (and GDB’s recent internal TLS code also has to cope with both “offset” and “VMA in PT_TLS” flavours), my goal in this patch is to make LLDB robust to both encodings:

* if the operand already looks like an offset, use it as‑is;

* if it looks like a VMA inside PT_TLS, subtract p_vaddr to recover the offset and then proceed in the same way.

https://github.com/llvm/llvm-project/pull/191410