[lldb] Architecture plugins should report the vector element order. NFC #157198
+23
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some targets like PowerPC store their - PowerPC little endian: little endian elements ordered 0, 1, 2, ... - PowerPC big endian: big endian elements ordered n-1, n-2, n-3, ... - ARM/MIPS little endian: little endian elements ordered 0, 1, 2, ... - ARM/MIPS big endian: big endian elements ordered 0, 1, 2, ... This matters when LLVM-IR values are transferred to/from target memory since LLVM-IR orders elements 0, 1, 2, ... regardless of endianness. This will be used in llvm#155000 by changes to the IRInterpreter to allow it to evaluate some vectors without executing on the target
|
@llvm/pr-subscribers-lldb Author: Daniel Sanders (dsandersllvm) ChangesSome targets like PowerPC store their
This matters when LLVM-IR values are transferred to/from target memory since LLVM-IR orders elements 0, 1, 2, ... regardless of endianness. This will be used in #155000 by changes to the IRInterpreter to allow it to evaluate some vectors without executing on the target Full diff: https://github.com/llvm/llvm-project/pull/157198.diff 3 Files Affected:
diff --git a/lldb/include/lldb/Core/Architecture.h b/lldb/include/lldb/Core/Architecture.h
index b6fc1a20e1e69..f039d05fe00fa 100644
--- a/lldb/include/lldb/Core/Architecture.h
+++ b/lldb/include/lldb/Core/Architecture.h
@@ -129,6 +129,17 @@ class Architecture : public PluginInterface {
RegisterContext ®_context) const {
return false;
}
+
+ /// Get the vector element order for this architecture. This determines how
+ /// vector elements are indexed. This matters in a few places such as reading/
+ /// writing LLVM-IR values to/from target memory. Some architectures use
+ /// little-endian element ordering where element 0 is at the lowest address
+ /// even when the architecture is otherwise big-endian (e.g. MIPS MSA, ARM
+ /// NEON), but some architectures like PowerPC may use big-endian element
+ /// ordering where element 0 is at the highest address.
+ virtual lldb::ByteOrder GetVectorElementOrder() const {
+ return lldb::eByteOrderLittle;
+ }
};
} // namespace lldb_private
diff --git a/lldb/source/Plugins/Architecture/PPC64/ArchitecturePPC64.cpp b/lldb/source/Plugins/Architecture/PPC64/ArchitecturePPC64.cpp
index b8fac55e41da7..a4690cc561a28 100644
--- a/lldb/source/Plugins/Architecture/PPC64/ArchitecturePPC64.cpp
+++ b/lldb/source/Plugins/Architecture/PPC64/ArchitecturePPC64.cpp
@@ -35,7 +35,8 @@ void ArchitecturePPC64::Terminate() {
std::unique_ptr<Architecture> ArchitecturePPC64::Create(const ArchSpec &arch) {
if (arch.GetTriple().isPPC64() &&
arch.GetTriple().getObjectFormat() == llvm::Triple::ObjectFormatType::ELF)
- return std::unique_ptr<Architecture>(new ArchitecturePPC64());
+ return std::unique_ptr<Architecture>(
+ new ArchitecturePPC64(arch.GetByteOrder()));
return nullptr;
}
@@ -60,3 +61,7 @@ void ArchitecturePPC64::AdjustBreakpointAddress(const Symbol &func,
addr.SetOffset(addr.GetOffset() + loffs);
}
+
+lldb::ByteOrder ArchitecturePPC64::GetVectorElementOrder() const {
+ return m_vector_element_order;
+}
diff --git a/lldb/source/Plugins/Architecture/PPC64/ArchitecturePPC64.h b/lldb/source/Plugins/Architecture/PPC64/ArchitecturePPC64.h
index 80f7f27b54cce..9a0edf371d539 100644
--- a/lldb/source/Plugins/Architecture/PPC64/ArchitecturePPC64.h
+++ b/lldb/source/Plugins/Architecture/PPC64/ArchitecturePPC64.h
@@ -30,9 +30,14 @@ class ArchitecturePPC64 : public Architecture {
void AdjustBreakpointAddress(const Symbol &func,
Address &addr) const override;
+ lldb::ByteOrder GetVectorElementOrder() const override;
+
private:
static std::unique_ptr<Architecture> Create(const ArchSpec &arch);
- ArchitecturePPC64() = default;
+ ArchitecturePPC64(lldb::ByteOrder vector_element_order)
+ : m_vector_element_order(vector_element_order) {}
+
+ lldb::ByteOrder m_vector_element_order;
};
} // namespace lldb_private
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some targets like PowerPC store their
This matters when LLVM-IR values are transferred to/from target memory since LLVM-IR orders elements 0, 1, 2, ... regardless of endianness.
This will be used in #155000 by changes to the IRInterpreter to allow it to evaluate some vectors without executing on the target