Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[lldb][test][FreeBSD] Account for spsr being 8 bytes in newer versions #84032

Closed
wants to merge 1 commit into from

Conversation

DavidSpickett
Copy link
Collaborator

Since https://reviews.freebsd.org/D38983, spsr (aka cpsr) is stored as an 8 byte value. However in lldb's structures it is a 32 bit value still.

The version number comes from
https://cgit.freebsd.org/src/commit/?id=ea3061526e9ce5d3b65932c1d3e4437abd556d65.

Since https://reviews.freebsd.org/D38983, spsr (aka cpsr) is stored
as an 8 byte value. However in lldb's structures it is a 32 bit value
still.

The version number comes from
https://cgit.freebsd.org/src/commit/?id=ea3061526e9ce5d3b65932c1d3e4437abd556d65.
@DavidSpickett DavidSpickett changed the title [lldb][test][FreeBSD] Account for spsr being 8 bytes [lldb][test][FreeBSD] Account for spsr being 8 bytes in newer versions Mar 5, 2024
@llvmbot llvmbot added the lldb label Mar 5, 2024
@llvmbot
Copy link
Collaborator

llvmbot commented Mar 5, 2024

@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)

Changes

Since https://reviews.freebsd.org/D38983, spsr (aka cpsr) is stored as an 8 byte value. However in lldb's structures it is a 32 bit value still.

The version number comes from
https://cgit.freebsd.org/src/commit/?id=ea3061526e9ce5d3b65932c1d3e4437abd556d65.


Full diff: https://github.com/llvm/llvm-project/pull/84032.diff

1 Files Affected:

  • (modified) lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp (+9)
diff --git a/lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp b/lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
index e541a34e6e22a0..70697766dd82ba 100644
--- a/lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
+++ b/lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
@@ -7,6 +7,7 @@
 //===----------------------------------------------------------------------===//
 
 // clang-format off
+#include <sys/param.h>
 #include <sys/types.h>
 #include <machine/reg.h>
 #if defined(__arm__)
@@ -362,7 +363,15 @@ TEST(RegisterContextFreeBSDTest, arm64) {
   EXPECT_GPR_ARM64(lr, lr);
   EXPECT_GPR_ARM64(sp, sp);
   EXPECT_GPR_ARM64(pc, elr);
+#if __FreeBSD_version >= 1400084
+  // LLDB assumes that cpsr is 32 bit but the kernel stores it as a 64 bit
+  // value.
+  EXPECT_THAT(GetRegParams(reg_ctx, gpr_cpsr_arm64),
+              ::testing::Pair(offsetof(reg, spsr), 4));
+#else
+  // Older kernels stored spsr as a 32 bit value.
   EXPECT_GPR_ARM64(cpsr, spsr);
+#endif
 
   size_t base_offset = reg_ctx.GetRegisterInfo()[fpu_v0_arm64].byte_offset;
 

@DavidSpickett
Copy link
Collaborator Author

This may also imply there is work to be done to make lldb show the upper 32 bits, but I'll leave that to the FreeBSD experts to decide.

@emaste
Copy link
Member

emaste commented May 1, 2024

CC @zxombie

@@ -362,7 +363,15 @@ TEST(RegisterContextFreeBSDTest, arm64) {
EXPECT_GPR_ARM64(lr, lr);
EXPECT_GPR_ARM64(sp, sp);
EXPECT_GPR_ARM64(pc, elr);
#if __FreeBSD_version >= 1400084
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be correct when the host running the debugger is the same as the target (or at least the same version) but we should handle this based on target version

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. Though these tests are likely only run on the machine that built them, but if lldb is loading a FreeBSD corefile it would need to know there was a difference. That at least needs checking, even if it may appear to "just work".

Making cross version core files work is more than I have time for here, so if any FreeBSD person wants to do a proper version of this fix, feel free.

(I did look for a runtime way to get __FreeBSD_version but none of the version strings I found contained the final part of the macro's value)

@DavidSpickett
Copy link
Collaborator Author

Fixing the general issue needs more attention, so I am abandoning this fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants