================
@@ -8,8 +8,18 @@
#include "lldb/Utility/RegisterType.h"
+#include <atomic>
+
using namespace lldb_private;
+namespace {
+std::atomic<uint64_t> g_next_register_type_uid{1};
+}
+
+RegisterType::RegisterType(RegisterTypeKind kind, std::string id)
+ : m_kind(kind), m_id(std::move(id)),
+ m_uid(g_next_register_type_uid.fetch_add(1, std::memory_order_relaxed))
{}
----------------
DavidSpickett wrote:
I'm trying to convince myself that this lldb process global UID is better than
using the heap address of the RegisterType.
In which scenarios does caching by the address of the RegisterType break, and
how does a process global ID solve that?
I am struggling to think of a scenario where RegisterTypeBuilderClang has a
longer lifetime than the process object that is providing the RegisterType.
But even if I'm right about that, I had to think way too hard about it. Which
feels like some type of bug waiting to happen. So if a global ID is basically
the same thing but easier to understand, then I think I'd be happy with it.
https://github.com/llvm/llvm-project/pull/215874
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
