Skip to content

[lldb][Process/FreeBSDKernel] Fix broken debugging on aarch64#180222

Merged
mchoo7 merged 9 commits intollvm:mainfrom
mchoo7:arm
Feb 18, 2026
Merged

[lldb][Process/FreeBSDKernel] Fix broken debugging on aarch64#180222
mchoo7 merged 9 commits intollvm:mainfrom
mchoo7:arm

Conversation

@mchoo7
Copy link
Copy Markdown
Contributor

@mchoo7 mchoo7 commented Feb 6, 2026

struct pcb for arm64 has changed In freebsd/freebsd-src@1c1f31a#diff-d07b4e228ca340857a90658e328d65f8dea9c5063e99197fbaaa046d97ae927c, which broke kernel debugging on AArch64. Add support for FreeBSD 14 and later by finding osreldate.

Until FreeBSD 13 (previous struct pcb contained information for all registers):

(lldb) register read
General Purpose Registers:
        x0 = 0x0000000000000000
        x1 = 0x0000000000000000
        x2 = 0x0000000000000000
        x3 = 0x0000000000000000
        x4 = 0x0000000000000000
        x5 = 0x0000000000000000
        x6 = 0x0000000000000000
        x7 = 0x0000000000000000
        x8 = 0x0000000000000000
        x9 = 0x0000000000000000
       x10 = 0x0000000000000000
       x11 = 0x0000000000000000
       x12 = 0x0000000000000000
       x13 = 0x0000000000000000
       x14 = 0x0000000000000000
       x15 = 0x0000000000000000
       x16 = 0x0000000000000000
       x17 = 0x0000000000000000
       x18 = 0x0000000000000000
       x19 = 0xffff000000b2e000  dumper_configs_mtx_sysuninit_sys_uninit + 16
       x20 = 0x0000000000000000
       x21 = 0xffff000000bce000  vop_spare1_desc + 24
       x22 = 0xffff000000c8a9b8  kernel`db_cmd_table
       x23 = 0xffff000000c8b000  kernel`db_lhistory + 1496
       x24 = 0x000000000000006c
       x25 = 0x0000000000000065
       x26 = 0x0000000000000068
       x27 = 0x0000000000000004
       x28 = 0xffff000000c8b4d1  kernel`db_tok_string + 1
        fp = 0xffff0002d751de60
        sp = 0xffff0002d751de60
        pc = 0xffff00000045ea78  kernel`dump_savectx + 20
2 registers were unavailable.

Since FreeBSD 14 (these are defined in the new struct pcb):

(lldb) register read
General Purpose Registers:
       x19 = 0xffff000000d65000  M_PLIMIT + 48
       x20 = 0xffff000000e23000  sdta_vfs_vop_vop_inotify_add_watch_return2 + 8
       x21 = 0xffffa7ff822b98a8
       x22 = 0xffff000000e23000  sdta_vfs_vop_vop_inotify_add_watch_return2 + 8
       x23 = 0xffff000000e23000  sdta_vfs_vop_vop_inotify_add_watch_return2 + 8
       x24 = 0xffff000000e23000  sdta_vfs_vop_vop_inotify_add_watch_return2 + 8
       x25 = 0xffff000000dc4000  _mod_metadata_md_its_fdt_gic_on_kernel + 16
       x26 = 0x0000000000000000
       x27 = 0x00004b4ad79674cc
       x28 = 0x0000000000000004
        fp = 0xffff00028f6f8380
        lr = 0xffff000000519e98  kernel`doadump + 60 at kern_shutdown.c:399:2
        sp = 0xffff00028f6f8380
        pc = 0x0000000081144c80
20 registers were unavailable.

@mchoo7 mchoo7 requested a review from JDevlieghere as a code owner February 6, 2026 16:20
@llvmbot llvmbot added the lldb label Feb 6, 2026
@llvmbot
Copy link
Copy Markdown
Member

llvmbot commented Feb 6, 2026

@llvm/pr-subscribers-lldb

Author: Minsoo Choo (mchoo7)

Changes

struct pcb for arm64 has changed In freebsd/freebsd-src@1c1f31a#diff-d07b4e228ca340857a90658e328d65f8dea9c5063e99197fbaaa046d97ae927c, which broke kernel debugging on AArch64. This updates to the latest pcb structure which has been in effect since FreeBSD 14.


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

1 Files Affected:

  • (modified) lldb/source/Plugins/Process/FreeBSDKernel/RegisterContextFreeBSDKernel_arm64.cpp (+13-28)
diff --git a/lldb/source/Plugins/Process/FreeBSDKernel/RegisterContextFreeBSDKernel_arm64.cpp b/lldb/source/Plugins/Process/FreeBSDKernel/RegisterContextFreeBSDKernel_arm64.cpp
index 11843ddc82d97..68944418b9a83 100644
--- a/lldb/source/Plugins/Process/FreeBSDKernel/RegisterContextFreeBSDKernel_arm64.cpp
+++ b/lldb/source/Plugins/Process/FreeBSDKernel/RegisterContextFreeBSDKernel_arm64.cpp
@@ -43,9 +43,10 @@ bool RegisterContextFreeBSDKernel_arm64::ReadRegister(
     return false;
 
   struct {
-    llvm::support::ulittle64_t x[30];
-    llvm::support::ulittle64_t lr;
-    llvm::support::ulittle64_t _reserved;
+#define	PCB_FP		10
+#define	PCB_LR		11
+
+    llvm::support::ulittle64_t x[12];
     llvm::support::ulittle64_t sp;
   } pcb;
 
@@ -57,25 +58,6 @@ bool RegisterContextFreeBSDKernel_arm64::ReadRegister(
 
   uint32_t reg = reg_info->kinds[lldb::eRegisterKindLLDB];
   switch (reg) {
-  case gpr_x0_arm64:
-  case gpr_x1_arm64:
-  case gpr_x2_arm64:
-  case gpr_x3_arm64:
-  case gpr_x4_arm64:
-  case gpr_x5_arm64:
-  case gpr_x6_arm64:
-  case gpr_x7_arm64:
-  case gpr_x8_arm64:
-  case gpr_x9_arm64:
-  case gpr_x10_arm64:
-  case gpr_x11_arm64:
-  case gpr_x12_arm64:
-  case gpr_x13_arm64:
-  case gpr_x14_arm64:
-  case gpr_x15_arm64:
-  case gpr_x16_arm64:
-  case gpr_x17_arm64:
-  case gpr_x18_arm64:
   case gpr_x19_arm64:
   case gpr_x20_arm64:
   case gpr_x21_arm64:
@@ -87,16 +69,19 @@ bool RegisterContextFreeBSDKernel_arm64::ReadRegister(
   case gpr_x27_arm64:
   case gpr_x28_arm64:
   case gpr_fp_arm64:
-    static_assert(gpr_fp_arm64 - gpr_x0_arm64 == 29,
+    static_assert(gpr_fp_arm64 - gpr_x19_arm64 == PCB_FP,
                   "nonconsecutive arm64 register numbers");
-    value = pcb.x[reg - gpr_x0_arm64];
-    break;
-  case gpr_sp_arm64:
-    value = pcb.sp;
+    value = pcb.x[reg - gpr_x19_arm64];
     break;
+  case gpr_lr_arm64:
   case gpr_pc_arm64:
     // The pc of crashing thread is stored in lr.
-    value = pcb.lr;
+    static_assert(gpr_lr_arm64 - gpr_x19_arm64 == PCB_LR,
+                  "nonconsecutive arm64 register numbers");
+    value = pcb.x[reg - gpr_x19_arm64];
+    break;
+  case gpr_sp_arm64:
+    value = pcb.sp;
     break;
   default:
     return false;

@github-actions
Copy link
Copy Markdown

github-actions bot commented Feb 6, 2026

✅ With the latest revision this PR passed the C/C++ code formatter.

Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
Copy link
Copy Markdown
Contributor

@kevans91 kevans91 left a comment

Choose a reason for hiding this comment

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

This is fine, though I note that it might be nice to avoid breaking pre-14.0 kernel debugging? If for nothing else but to establish the infrastructure to grab a __FreeBSD_version from the target (if it doesn't exist) and use that for runtime compat. I realize that it's a tough sell with 13.5 going out of support in just a few short months, though.

@mchoo7
Copy link
Copy Markdown
Contributor Author

mchoo7 commented Feb 6, 2026

This is fine, though I note that it might be nice to avoid breaking pre-14.0 kernel debugging? If for nothing else but to establish the infrastructure to grab a __FreeBSD_version from the target (if it doesn't exist) and use that for runtime compat. I realize that it's a tough sell with 13.5 going out of support in just a few short months, though.

Although dropping stable/13 support was approved #179587, @emaste approved because it was text-only approval (not actually breaking stable/13). This change definitely breaks stable/13 so I need approval from him again.

@emaste
Copy link
Copy Markdown
Member

emaste commented Feb 6, 2026

I note that it might be nice to avoid breaking pre-14.0 kernel debugging?

If we can do so without too much work I think it's worth doing. That said, I'd much rather have 14.x+ fixed than have 13.x support, so I would be fine with this change going in and then adding 13.x backwards compat in a followup.

@mchoo7
Copy link
Copy Markdown
Contributor Author

mchoo7 commented Feb 6, 2026

If we can do so without too much work I think it's worth doing. That said, I'd much rather have 14.x+ fixed than have 13.x support, so I would be fine with this change going in and then adding 13.x backwards compat in a followup.

I think it's better to add fixes for both post-14 and 13 in this PR and backport to LLVM 22.

@mchoo7 mchoo7 force-pushed the arm branch 2 times, most recently from 3a4317a to 746831a Compare February 6, 2026 19:07
@mchoo7 mchoo7 requested a review from kevans91 February 6, 2026 19:08
@mchoo7
Copy link
Copy Markdown
Contributor Author

mchoo7 commented Feb 6, 2026

@kevans91 could you test this on arm64?

Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
@kevans91
Copy link
Copy Markdown
Contributor

kevans91 commented Feb 6, 2026

@kevans91 could you test this on arm64?

Sure, but probably won't have time until Monday at least.

@mchoo7
Copy link
Copy Markdown
Contributor Author

mchoo7 commented Feb 6, 2026

@kevans91 could you test this on arm64?

Sure, but probably won't have time until Monday at least.

No problem. I'll get a dump from Ampere on Sunday.

@mchoo7 mchoo7 force-pushed the arm branch 2 times, most recently from d5f1858 to 1f04ae0 Compare February 9, 2026 15:05
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
@mchoo7
Copy link
Copy Markdown
Contributor Author

mchoo7 commented Feb 11, 2026

@DavidSpickett This change is now tested natively on aarch64. I updated the PR description for results.

@mchoo7
Copy link
Copy Markdown
Contributor Author

mchoo7 commented Feb 11, 2026

Is this subject to last minute backporting for llvm 22?

Copy link
Copy Markdown
Collaborator

@DavidSpickett DavidSpickett left a comment

Choose a reason for hiding this comment

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

Is this subject to last minute backporting for llvm 22?

The final RC of 22 was just released so there is still time for a backport. This must be approved and known to not have caused problems, before a backport can happen.

For future reference the process for a backport is https://llvm.org/docs/GitHub.html#backporting.

This seems like a significant fix for lldb users, so I suggest including a release note in the backport. If the backport is rejected, then we can add said release note to main instead, in a separate PR.

As FreeBSD related people raised concerns here about the version handling (@kevans91), I want to see an approval from at least one of them, even if it's only on that topic.

I have left some comments but it's just style at this point. If a FreeBSD reviewer is happy with it, then I am.

Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
@mchoo7 mchoo7 temporarily deployed to main-branch-only February 12, 2026 14:38 — with GitHub Actions Inactive
@mchoo7 mchoo7 temporarily deployed to main-branch-only February 12, 2026 15:41 — with GitHub Actions Inactive
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
@mchoo7 mchoo7 temporarily deployed to main-branch-only February 12, 2026 15:44 — with GitHub Actions Inactive
@mchoo7 mchoo7 temporarily deployed to main-branch-only February 12, 2026 16:04 — with GitHub Actions Inactive
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
Copy link
Copy Markdown
Collaborator

@DavidSpickett DavidSpickett left a comment

Choose a reason for hiding this comment

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

LGTM but this can only be merged when there is also a FreeBSD approval.

Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
@mchoo7 mchoo7 merged commit 4f0eb3d into llvm:main Feb 18, 2026
10 checks passed
@mchoo7 mchoo7 deleted the arm branch February 18, 2026 20:20
// The pc of crashing thread is stored in lr.
static_assert(gpr_lr_arm64 - gpr_x19_arm64 == PCB_LR,
"nonconsecutive arm64 register numbers");
value = pcb.x[reg - gpr_x19_arm64];
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

This does the wrong thing for gpr_pc_arm64, it's one past the end, so reads sp. Presumably this is meant to be always gpr_lr_arm64 - gpr_x19_arm64, i.e. PCB_LR?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I created fix for this at #183947

mchoo7 added a commit that referenced this pull request Mar 2, 2026
)

Since `pcb.lr` always contains the value of pc, `gpr_lr_arm64` should be
unavailable. This also fixes the case where `gpr_pc_arm64` displays sp
not lr field in pcb.

Reported by: jrtc27
Fixes: 4f0eb3d (#180222)

---------

Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
sahas3 pushed a commit to sahas3/llvm-project that referenced this pull request Mar 4, 2026
…#183947)

Since `pcb.lr` always contains the value of pc, `gpr_lr_arm64` should be
unavailable. This also fixes the case where `gpr_pc_arm64` displays sp
not lr field in pcb.

Reported by: jrtc27
Fixes: 4f0eb3d (llvm#180222)

---------

Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
sujianIBM pushed a commit to sujianIBM/llvm-project that referenced this pull request Mar 5, 2026
…#183947)

Since `pcb.lr` always contains the value of pc, `gpr_lr_arm64` should be
unavailable. This also fixes the case where `gpr_pc_arm64` displays sp
not lr field in pcb.

Reported by: jrtc27
Fixes: 4f0eb3d (llvm#180222)

---------

Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
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.

6 participants