================
@@ -1568,15 +1569,16 @@ bool Target::SetArchitecture(const ArchSpec &arch_spec,
bool set_platform,
if (m_arch.GetSpec().IsCompatibleMatch(other)) {
compatible_local_arch = true;
- bool arch_changed, vendor_changed, os_changed, os_ver_changed,
- env_changed;
- m_arch.GetSpec().PiecewiseTripleCompare(other, arch_changed,
- vendor_changed, os_changed,
- os_ver_changed, env_changed);
-
- if (!arch_changed && !vendor_changed && !os_changed && !env_changed)
+ if (m_arch.GetSpec().GetTriple() == other.GetTriple())
replace_local_arch = false;
+ // Workaround for for pre-2024 debugserver, which always
+ // returns arm64e on arm64e-capable hardware regardless of
+ // what the process is. This can be deleted at some point in
+ // the future.
----------------
JDevlieghere wrote:
We face the exact same issue with the compiler and pretty much all other llvm
tools that follow that versioning scheme. In other words I don't think we
should go out of our way to fix that just for debugserver. A simple heuristic
could be version < 1000 is llvm version and > 1000 is the Apple version and
possibly have a table as those releases aren't necessary aligned.
https://github.com/llvm/llvm-project/pull/82938
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
