[Lldb-commits] [lldb] [LLDB] Enable TLS Variable Debugging Without Location Info on AArch64 (PR #110822)

[Greg Clayton via lldb-commits]

================
@@ -254,7 +254,38 @@ bool ValueObjectVariable::UpdateValue() {
       m_resolved_value.SetContext(Value::ContextType::Invalid, nullptr);
     }
   }
-
+  if (m_error.Fail() && variable->IsThreadLocal()) {
+    ExecutionContext exe_ctx(GetExecutionContextRef());
+    Thread *thread = exe_ctx.GetThreadPtr();
+    lldb::ModuleSP module_sp = GetModule();
+    if (!thread) {
+      m_error = Status::FromErrorString("no thread to evaluate TLS within");
+      return m_error.Success();
+    }
+    std::vector<uint32_t> symbol_indexes;
+    module_sp->GetSymtab()->FindAllSymbolsWithNameAndType(
+        ConstString(variable->GetName()), lldb::SymbolType::eSymbolTypeAny,
+        symbol_indexes);
+    Symbol *symbol = module_sp->GetSymtab()->SymbolAtIndex(symbol_indexes[0]);
+    lldb::addr_t tls_file_addr =
+        symbol->GetAddress().GetOffset() +
+        symbol->GetAddress().GetSection()->GetFileAddress();
----------------
clayborg wrote:

This seems very specify to the way that the current OS encodes thread local data. What does this work on right now? Linux only I assume? This seems like this functionality should be in OS specific code. Maybe the ABI plug-ins so that if this is a Linux thing, if the OS ABI defines a way to get variables for thread locals, we encapsulate this so this doesn't say try to run on windows, or other systems. So I would suggest using the target triple of the target to get an appropriate OS ABI or other architecture specific plug-in (ARM64) and then doing this work there only if the target triple matches arm64-linux-....

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