[lldb] Do not produce field information for registers known not to exist #95125
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
Currently the logic is generate field information for all registers in LinuxArm64RegisterFlags and then as we walk the existing register info, only those that are in that existing info will get the new fields patched in. This works fine but on a review for FreeBSD support it was pointed out that this is not obvious from the source code. So instead I've allowed the construction of empty lists of fields, and field detection methods can return an empty field list if they think that the register will never exist. Then the pre-existing code will see the empty field list, and never look for that register in the register info. I think removing the assert is ok because the GDB classes filter out empty field lists at runtime, and anyone updating the built in field information would presumably notice if none of the fields they intended to add were displayed. mte_ctrl and svcr are the only registers that need this so far. There is no extra testing here as the behaviour is the same, it doesn't add field information to regiters that don't exist. The mechanism is just clearer now.
|
@llvm/pr-subscribers-lldb Author: David Spickett (DavidSpickett) ChangesCurrently the logic is generate field information for all registers in LinuxArm64RegisterFlags and then as we walk the existing register info, only those that are in that existing info will get the new fields patched in. This works fine but on a review for FreeBSD support it was pointed out that this is not obvious from the source code. So instead I've allowed the construction of empty lists of fields, and field detection methods can return an empty field list if they think that the register will never exist. Then the pre-existing code will see the empty field list, and never look for that register in the register info. I think removing the assert is ok because the GDB classes filter out empty field lists at runtime, and anyone updating the built in field information would presumably notice if none of the fields they intended to add were displayed. mte_ctrl and svcr are the only registers that need this so far. There is no extra testing here as the behaviour is the same, it doesn't add field information to regiters that don't exist. The mechanism is just clearer now. Full diff: https://github.com/llvm/llvm-project/pull/95125.diff 3 Files Affected:
diff --git a/lldb/source/Plugins/Process/Utility/RegisterFlagsLinux_arm64.cpp b/lldb/source/Plugins/Process/Utility/RegisterFlagsLinux_arm64.cpp
index 51553817921f3..8ed75d700f225 100644
--- a/lldb/source/Plugins/Process/Utility/RegisterFlagsLinux_arm64.cpp
+++ b/lldb/source/Plugins/Process/Utility/RegisterFlagsLinux_arm64.cpp
@@ -20,6 +20,7 @@
#define HWCAP2_BTI (1ULL << 17)
#define HWCAP2_MTE (1ULL << 18)
#define HWCAP2_AFP (1ULL << 20)
+#define HWCAP2_SME (1ULL << 23)
#define HWCAP2_EBF16 (1ULL << 32)
using namespace lldb_private;
@@ -27,7 +28,10 @@ using namespace lldb_private;
LinuxArm64RegisterFlags::Fields
LinuxArm64RegisterFlags::DetectSVCRFields(uint64_t hwcap, uint64_t hwcap2) {
(void)hwcap;
- (void)hwcap2;
+
+ if (!(hwcap2 & HWCAP2_SME))
+ return {};
+
// Represents the pseudo register that lldb-server builds, which itself
// matches the architectural register SCVR. The fields match SVCR in the Arm
// manual.
@@ -40,7 +44,10 @@ LinuxArm64RegisterFlags::DetectSVCRFields(uint64_t hwcap, uint64_t hwcap2) {
LinuxArm64RegisterFlags::Fields
LinuxArm64RegisterFlags::DetectMTECtrlFields(uint64_t hwcap, uint64_t hwcap2) {
(void)hwcap;
- (void)hwcap2;
+
+ if (!(hwcap2 & HWCAP2_MTE))
+ return {};
+
// Represents the contents of NT_ARM_TAGGED_ADDR_CTRL and the value passed
// to prctl(PR_TAGGED_ADDR_CTRL...). Fields are derived from the defines
// used to build the value.
diff --git a/lldb/source/Plugins/Process/Utility/RegisterFlagsLinux_arm64.h b/lldb/source/Plugins/Process/Utility/RegisterFlagsLinux_arm64.h
index 660bef08700f4..49b1d90db64f6 100644
--- a/lldb/source/Plugins/Process/Utility/RegisterFlagsLinux_arm64.h
+++ b/lldb/source/Plugins/Process/Utility/RegisterFlagsLinux_arm64.h
@@ -38,8 +38,8 @@ class LinuxArm64RegisterFlags {
/// For the registers listed in this class, detect which fields are
/// present. Must be called before UpdateRegisterInfos.
/// If called more than once, fields will be redetected each time from
- /// scratch. If you do not have access to hwcap, just pass 0 for each one, you
- /// will only get unconditional fields.
+ /// scratch. If the target would not have this register at all, the list of
+ /// fields will be left empty.
void DetectFields(uint64_t hwcap, uint64_t hwcap2);
/// Add the field information of any registers named in this class,
@@ -63,7 +63,7 @@ class LinuxArm64RegisterFlags {
struct RegisterEntry {
RegisterEntry(llvm::StringRef name, unsigned size, DetectorFn detector)
- : m_name(name), m_flags(std::string(name) + "_flags", size, {{"", 0}}),
+ : m_name(name), m_flags(std::string(name) + "_flags", size, {}),
m_detector(detector) {}
llvm::StringRef m_name;
diff --git a/lldb/source/Target/RegisterFlags.cpp b/lldb/source/Target/RegisterFlags.cpp
index 5274960587bf3..de9f12649e2ec 100644
--- a/lldb/source/Target/RegisterFlags.cpp
+++ b/lldb/source/Target/RegisterFlags.cpp
@@ -54,10 +54,6 @@ unsigned RegisterFlags::Field::PaddingDistance(const Field &other) const {
}
void RegisterFlags::SetFields(const std::vector<Field> &fields) {
- // We expect that the XML processor will discard anything describing flags but
- // with no fields.
- assert(fields.size() && "Some fields must be provided.");
-
// We expect that these are unsorted but do not overlap.
// They could fill the register but may have gaps.
std::vector<Field> provided_fields = fields;
|
|
#85058 is the FreeBSD change, it'll get rebased onto this later. |
lravenclaw
pushed a commit
to lravenclaw/llvm-project
that referenced
this pull request
Jul 3, 2024
…ist (llvm#95125) Currently the logic is generate field information for all registers in LinuxArm64RegisterFlags and then as we walk the existing register info, only those that are in that existing info will get the new fields patched in. This works fine but on a review for FreeBSD support it was pointed out that this is not obvious from the source code. So instead I've allowed the construction of empty lists of fields, and field detection methods can return an empty field list if they think that the register will never exist. Then the pre-existing code will see the empty field list, and never look for that register in the register info. I think removing the assert is ok because the GDB classes filter out empty field lists at runtime, and anyone updating the built in field information would presumably notice if none of the fields they intended to add were displayed. mte_ctrl and svcr are the only registers that need this so far. There is no extra testing here as the behaviour is the same, it doesn't add field information to regiters that don't exist. The mechanism is just clearer now.
AlexisPerry
pushed a commit
to llvm-project-tlp/llvm-project
that referenced
this pull request
Jul 9, 2024
…ist (llvm#95125) Currently the logic is generate field information for all registers in LinuxArm64RegisterFlags and then as we walk the existing register info, only those that are in that existing info will get the new fields patched in. This works fine but on a review for FreeBSD support it was pointed out that this is not obvious from the source code. So instead I've allowed the construction of empty lists of fields, and field detection methods can return an empty field list if they think that the register will never exist. Then the pre-existing code will see the empty field list, and never look for that register in the register info. I think removing the assert is ok because the GDB classes filter out empty field lists at runtime, and anyone updating the built in field information would presumably notice if none of the fields they intended to add were displayed. mte_ctrl and svcr are the only registers that need this so far. There is no extra testing here as the behaviour is the same, it doesn't add field information to regiters that don't exist. The mechanism is just clearer now.
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.
Currently the logic is generate field information for all registers in LinuxArm64RegisterFlags and then as we walk the existing register info, only those that are in that existing info will get the new fields patched in.
This works fine but on a review for FreeBSD support it was pointed out that this is not obvious from the source code.
So instead I've allowed the construction of empty lists of fields, and field detection methods can return an empty field list if they think that the register will never exist.
Then the pre-existing code will see the empty field list, and never look for that register in the register info.
I think removing the assert is ok because the GDB classes filter out empty field lists at runtime, and anyone updating the built in field information would presumably notice if none of the fields they intended to add were displayed.
mte_ctrl and svcr are the only registers that need this so far.
There is no extra testing here as the behaviour is the same, it doesn't add field information to regiters that don't exist. The mechanism is just clearer now.