Skip to content

Conversation

@b10902118
Copy link
Contributor

@b10902118 b10902118 commented Jul 6, 2025

When debugging arm32 process on arm64 machine, arm64 lldb-server will use NativeRegisterContextLinux_arm, but the server should keep using 64-bit ptrace commands for hardware watchpoint/breakpoint, even when debugging a 32-bit tracee.

See: torvalds/linux@5d220ff

There have been many conditional compilation handling arm32 tracee on arm64, but this one is missed out.

To reuse the 64-bit implementation, I separate the shared code from NativeRegisterContextLinux_arm64.cpp to NativeRegisterContextLinux_arm64dbreg.cpp, with other adjustments to share data structures of debug registers.

@b10902118 b10902118 requested a review from JDevlieghere as a code owner July 6, 2025 16:12
@github-actions
Copy link

github-actions bot commented Jul 6, 2025

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

@llvmbot llvmbot added the lldb label Jul 6, 2025
@llvmbot
Copy link
Member

llvmbot commented Jul 6, 2025

@llvm/pr-subscribers-lldb

Author: None (b10902118)

Changes

This bug skips the test because the wrong ptrace call to detect avaliable hardware/breakpoint number that resuls in 0.

After tracing linux's compat_ptrace in arch/arm64/kernel/ptrace.c, found that arm64 lldb-server should just keep using the ptrace commands for 64bit tracees. See: torvalds/linux@5d220ff

So the solution is copying the implementation in NativeRegisterContextLinux_arm64.cpp.


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

2 Files Affected:

  • (modified) lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp (+73-2)
  • (modified) lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.h (+1-1)
diff --git a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
index dc7fb103e87c0..9123a577008bd 100644
--- a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
+++ b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
@@ -23,13 +23,18 @@
 #include <elf.h>
 #include <sys/uio.h>
 
+#if defined(__arm64__) || defined(__aarch64__)
+#include "lldb/Host/linux/Ptrace.h"
+#include <asm/ptrace.h>
+#endif
+
 #define REG_CONTEXT_SIZE (GetGPRSize() + sizeof(m_fpr))
 
 #ifndef PTRACE_GETVFPREGS
 #define PTRACE_GETVFPREGS 27
 #define PTRACE_SETVFPREGS 28
 #endif
-#ifndef PTRACE_GETHBPREGS
+#if defined(__arm__) && !defined(PTRACE_GETHBPREGS)
 #define PTRACE_GETHBPREGS 29
 #define PTRACE_SETHBPREGS 30
 #endif
@@ -723,6 +728,7 @@ Status NativeRegisterContextLinux_arm::ReadHardwareDebugInfo() {
     return Status();
   }
 
+#ifdef __arm__
   unsigned int cap_val;
 
   error = NativeProcessLinux::PtraceWrapper(PTRACE_GETHBPREGS, m_thread.GetID(),
@@ -737,12 +743,43 @@ Status NativeRegisterContextLinux_arm::ReadHardwareDebugInfo() {
   m_refresh_hwdebug_info = false;
 
   return error;
+#else  // __aarch64__
+  ::pid_t tid = m_thread.GetID();
+
+  int regset = NT_ARM_HW_WATCH;
+  struct iovec ioVec;
+  struct user_hwdebug_state dreg_state;
+
+  ioVec.iov_base = &dreg_state;
+  ioVec.iov_len = sizeof(dreg_state);
+
+  error = NativeProcessLinux::PtraceWrapper(PTRACE_GETREGSET, tid, &regset,
+                                            &ioVec, ioVec.iov_len);
+
+  if (error.Fail())
+    return error;
+
+  m_max_hwp_supported = dreg_state.dbg_info & 0xff;
+
+  regset = NT_ARM_HW_BREAK;
+  error = NativeProcessLinux::PtraceWrapper(PTRACE_GETREGSET, tid, &regset,
+                                            &ioVec, ioVec.iov_len);
+
+  if (error.Fail())
+    return error;
+
+  m_max_hbp_supported = dreg_state.dbg_info & 0xff;
+  m_refresh_hwdebug_info = false;
+
+  return error;
+#endif // __arm__
 }
 
-Status NativeRegisterContextLinux_arm::WriteHardwareDebugRegs(int hwbType,
+Status NativeRegisterContextLinux_arm::WriteHardwareDebugRegs(DREGType hwbType,
                                                               int hwb_index) {
   Status error;
 
+#ifdef __arm__
   lldb::addr_t *addr_buf;
   uint32_t *ctrl_buf;
 
@@ -781,6 +818,40 @@ Status NativeRegisterContextLinux_arm::WriteHardwareDebugRegs(int hwbType,
   }
 
   return error;
+#else  // __aarch64__
+  struct iovec ioVec;
+  struct user_hwdebug_state dreg_state;
+  int regset;
+
+  memset(&dreg_state, 0, sizeof(dreg_state));
+  ioVec.iov_base = &dreg_state;
+
+  switch (hwbType) {
+  case eDREGTypeWATCH:
+    regset = NT_ARM_HW_WATCH;
+    ioVec.iov_len = sizeof(dreg_state.dbg_info) + sizeof(dreg_state.pad) +
+                    (sizeof(dreg_state.dbg_regs[0]) * m_max_hwp_supported);
+
+    for (uint32_t i = 0; i < m_max_hwp_supported; i++) {
+      dreg_state.dbg_regs[i].addr = m_hwp_regs[i].address;
+      dreg_state.dbg_regs[i].ctrl = m_hwp_regs[i].control;
+    }
+    break;
+  case eDREGTypeBREAK:
+    regset = NT_ARM_HW_BREAK;
+    ioVec.iov_len = sizeof(dreg_state.dbg_info) + sizeof(dreg_state.pad) +
+                    (sizeof(dreg_state.dbg_regs[0]) * m_max_hbp_supported);
+
+    for (uint32_t i = 0; i < m_max_hbp_supported; i++) {
+      dreg_state.dbg_regs[i].addr = m_hbr_regs[i].address;
+      dreg_state.dbg_regs[i].ctrl = m_hbr_regs[i].control;
+    }
+    break;
+  }
+
+  return NativeProcessLinux::PtraceWrapper(PTRACE_SETREGSET, m_thread.GetID(),
+                                           &regset, &ioVec, ioVec.iov_len);
+#endif // __arm__
 }
 
 uint32_t NativeRegisterContextLinux_arm::CalculateFprOffset(
diff --git a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.h b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.h
index 15b46609c286b..6d0ad38d7eb75 100644
--- a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.h
+++ b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.h
@@ -125,7 +125,7 @@ class NativeRegisterContextLinux_arm : public NativeRegisterContextLinux {
 
   Status ReadHardwareDebugInfo();
 
-  Status WriteHardwareDebugRegs(int hwbType, int hwb_index);
+  Status WriteHardwareDebugRegs(DREGType hwbType, int hwb_index);
 
   uint32_t CalculateFprOffset(const RegisterInfo *reg_info) const;
 

@labath labath requested a review from DavidSpickett July 7, 2025 07:55
@labath
Copy link
Collaborator

labath commented Jul 7, 2025

Your analysis is correct -- the kernel uses the bitwidth of the tracer (not the tracee) when deciding whether to use the compatibility interface. However, copying the code sounds like a fairly fragile solution. It'd be better to figure out a way to share the code somehow.

The x86 classes don't have this problem because NativeRegisterContextLinux_x86_64 knows how to debug both 32 and 64-bit processes. That may not be the right solution here, but it's one thing you can use for inspiration.

@b10902118
Copy link
Contributor Author

Oh thanks you make it clear. This fix actually follows kernel's 64bit logic. I wrongly mentioned compat_ptrace, which is for 32bit tracer use old HBP commands.

@DavidSpickett
Copy link
Collaborator

the test

By this you mean it skips any test that requires hardware breakpoints? Or you mean that in the general course of using lldb it doesn't use hardware breakpoints because of this?

(I assume you could make the test suite launch all debugees as AArch32 but seems unlikely you went to that effort)

@DavidSpickett
Copy link
Collaborator

So the solution is copying the implementation in NativeRegisterContextLinux_arm64.cpp.

Yes, try putting the 64-bit code in a separate file in Process/Linux then using it in both places.

Currently arm64 includes the arm header, for reasons I am not sure, so if there is a dependency, it's going the wrong way for us to use it for this.

@b10902118
Copy link
Contributor Author

b10902118 commented Jul 9, 2025

the test

By this you mean it skips any test that requires hardware breakpoints? Or you mean that in the general course of using lldb it doesn't use hardware breakpoints because of this?

(I assume you could make the test suite launch all debugees as AArch32 but seems unlikely you went to that effort)

Oh sorry please ignore that. I mixed lldb's test up with other sources (probably android's), making a wrong comment.

@b10902118
Copy link
Contributor Author

So the solution is copying the implementation in NativeRegisterContextLinux_arm64.cpp.

Yes, try putting the 64-bit code in a separate file in Process/Linux then using it in both places.

Currently arm64 includes the arm header, for reasons I am not sure, so if there is a dependency, it's going the wrong way for us to use it for this.

The include of arm header is just for the factory function CreateHostNativeRegisterContextLinux to return NativeRegisterContextLinux_arm for arm32 process, tested by removing only that part and compiling.

@labath
Copy link
Collaborator

labath commented Jul 10, 2025

That's correct, and my earlier question basically was what if we make CreateHostNativeRegisterContextLinux return NativeRegisterContextLinux_arm64 for arm-on-arm64 debugging. Given that you're copying a part of _arm64 into _arm32, I am wondering whether the arm-on-arm64 case isn't actually more similar to arm64-on-arm64 than it is to arm32-onarm32.

@DavidSpickett
Copy link
Collaborator

I am wondering whether the arm-on-arm64 case isn't actually more similar to arm64-on-arm64 than it is to arm32-onarm32.

If arm64 did not have umpteen kinds of registers maybe, but going by the header the only common bit would be the detection and writing of breakpoint registers (for some reason I thought we would also read them back but no of course we don't need to do that).

I haven't tried actually debugging something though so maybe there's more here that doesn't work.

...if there is a way to hack the test suite config to produce AArch32 that's one way to find that out. CMake options LLDB_TEST_COMPILER and LLDB_TEST_ARCH maybe. See how terrible the results are.

@b10902118
Copy link
Contributor Author

Sorry for the delay. I tried to first let NativeRegisterContextLinux_arm inherit NativeRegisterContextDBReg as arm64. That seems to work but is a big change, so maybe starting from here is a better idea.

@b10902118
Copy link
Contributor Author

b10902118 commented Jul 20, 2025

I have run API tests on watchpoint (-p '.*Watch.*', not sure how to do it correctly, running all takes too long), and it maintains the same 7 failures so I assmue my modification won't break things.

The new commit message is for this PR. To merge, please use that. (I have no commit access)

Copy link
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.

Some small comments and you'll need to rebase when the cleanup PR lands. It's good to go in once that's done.

@DavidSpickett
Copy link
Collaborator

From the PR description:

After tracing linux's compat_ptrace in arch/arm64/kernel/ptrace.c, found that arm64 lldb-server should just keep using the ptrace commands for 64bit tracees.

Reword this so it's a bit clearer. I get what you mean now, but I had to read it several times.

"lldb-server should keep using the ptrace commands intended for 64-bit bit tracees, even when debugging a 32-bit tracee"

@DavidSpickett
Copy link
Collaborator

Linux CI failure is:

2025-07-28T08:45:11.0284286Z sccache /opt/llvm/bin/clang++ -DEXPERIMENTAL_KEY_INSTRUCTIONS -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -D_DEBUG -D_GLIBCXX_ASSERTIONS -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__SHORT_FILE__=\"NativeRegisterContextLinux_arm64dbreg.cpp\" -I/home/gha/actions-runner/_work/llvm-project/llvm-project/build/tools/lldb/source/Plugins/Process/Linux -I/home/gha/actions-runner/_work/llvm-project/llvm-project/lldb/source/Plugins/Process/Linux -I/home/gha/actions-runner/_work/llvm-project/llvm-project/lldb/include -I/home/gha/actions-runner/_work/llvm-project/llvm-project/build/tools/lldb/include -I/home/gha/actions-runner/_work/llvm-project/llvm-project/build/include -I/home/gha/actions-runner/_work/llvm-project/llvm-project/llvm/include -I/usr/include/python3.12 -I/home/gha/actions-runner/_work/llvm-project/llvm-project/llvm/../clang/include -I/home/gha/actions-runner/_work/llvm-project/llvm-project/build/tools/lldb/../clang/include -I/home/gha/actions-runner/_work/llvm-project/llvm-project/lldb/source -I/home/gha/actions-runner/_work/llvm-project/llvm-project/build/tools/lldb/source -gmlt -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-vla-extension -O3 -DNDEBUG -std=c++17  -fno-exceptions -funwind-tables -fno-rtti -UNDEBUG -MD -MT tools/lldb/source/Plugins/Process/Linux/CMakeFiles/lldbPluginProcessLinux.dir/NativeRegisterContextLinux_arm64dbreg.cpp.o -MF tools/lldb/source/Plugins/Process/Linux/CMakeFiles/lldbPluginProcessLinux.dir/NativeRegisterContextLinux_arm64dbreg.cpp.o.d -o tools/lldb/source/Plugins/Process/Linux/CMakeFiles/lldbPluginProcessLinux.dir/NativeRegisterContextLinux_arm64dbreg.cpp.o -c /home/gha/actions-runner/_work/llvm-project/llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64dbreg.cpp
2025-07-28T08:45:11.0299743Z /home/gha/actions-runner/_work/llvm-project/llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64dbreg.cpp:26:29: error: variable has incomplete type 'struct user_hwdebug_state'
2025-07-28T08:45:11.0301314Z    26 |   struct user_hwdebug_state dreg_state;
2025-07-28T08:45:11.0301735Z       |                             ^
2025-07-28T08:45:11.0302987Z /home/gha/actions-runner/_work/llvm-project/llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64dbreg.cpp:26:10: note: forward declaration of 'user_hwdebug_state'
2025-07-28T08:45:11.0304281Z    26 |   struct user_hwdebug_state dreg_state;
2025-07-28T08:45:11.0304681Z       |          ^
2025-07-28T08:45:11.0305917Z /home/gha/actions-runner/_work/llvm-project/llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64dbreg.cpp:56:29: error: variable has incomplete type 'struct user_hwdebug_state'
2025-07-28T08:45:11.0307300Z    56 |   struct user_hwdebug_state dreg_state;
2025-07-28T08:45:11.0307782Z       |                             ^
2025-07-28T08:45:11.0309023Z /home/gha/actions-runner/_work/llvm-project/llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64dbreg.cpp:56:10: note: forward declaration of 'user_hwdebug_state'
2025-07-28T08:45:11.0310341Z    56 |   struct user_hwdebug_state dreg_state;
2025-07-28T08:45:11.0310890Z       |          ^
2025-07-28T08:45:11.0311164Z 2 errors generated.

@b10902118
Copy link
Contributor Author

Reword this so it's a bit clearer. I get what you mean now, but I had to read it several times.

Sure! Sorry for causing the confusion. I have updated the description with the new message in the second commit and your suggestion.

@b10902118
Copy link
Contributor Author

I am fixing the ci failure. Just wonder how you guys prevent this? I can build locally and clangd also didn't complain in my editor.

@DavidSpickett
Copy link
Collaborator

DavidSpickett commented Jul 28, 2025

Yeah that is odd. Is it because NativeRegisterContextLinux_arm64dbreg.cpp is being built even when we're not compiling lldb-server for AArch64 or Arm? Perhaps because you are on an AArch64 machine that's why it works for you?

Edit: because the CI is x86_64.

@b10902118
Copy link
Contributor Author

Edit: because the CI is x86_64.

Thanks for pointing that out. The failure is probably cause by the missing #if defined(__arm64__) || defined(__aarch64__). I finally understand why this is needed.

@b10902118
Copy link
Contributor Author

Oh no I massed it up with github's conflict resolve. I still have to fix my previous no-reply commit.

@b10902118 b10902118 force-pushed the main branch 2 times, most recently from d2bb930 to 4fdef06 Compare July 28, 2025 16:47
…cess.

This bug skips the test because the wrong ptrace call to detect avaliable hardware/breakpoint number that resuls in 0.

After tracing linux's compat_ptrace in arch/arm64/kernel/ptrace.c, found that arm64 lldb-server should just keep using the ptrace commands for 64bit tracees. See:
torvalds/linux@5d220ff

So the solution is copying the implementation in NativeRegisterContextLinux_arm64.cpp.
…n arm64.

When debugging arm32 process on arm64 machine, arm64 lldb-server will use `NativeRegisterContextLinux_arm`, but it should use 64-bit ptrace commands for hardware watchpoint/breakpoint.
See: torvalds/linux@5d220ff

There have been many conditional compilation handling arm32 debuggees on arm64, but this one is missed out.

To reuse the 64-bit implementation, I separate the shared code from `NativeRegisterContextLinux_arm64.cpp` to `NativeRegisterContextLinuxArm64Shared.cpp`, with other adjustments to share data structures of debug registers.
@b10902118
Copy link
Contributor Author

Sorry again. I made a big mass. Just tried to recover the history but...
The last five commits are today's changes. Hope that be more readable.

@DavidSpickett
Copy link
Collaborator

If it helps, people (including me) have made much bigger messes :)

We're all good, going to merge this now.

@DavidSpickett DavidSpickett merged commit 9bf3e61 into llvm:main Jul 29, 2025
9 checks passed
@github-actions
Copy link

@b10902118 Congratulations on having your first Pull Request (PR) merged into the LLVM Project!

Your changes will be combined with recent changes from other authors, then tested by our build bots. If there is a problem with a build, you may receive a report in an email or a comment on this PR.

Please check whether problems have been caused by your change specifically, as the builds can include changes from many authors. It is not uncommon for your change to be included in a build that fails due to someone else's changes, or infrastructure issues.

How to do this, and the rest of the post-merge process, is covered in detail here.

If your change does cause a problem, it may be reverted, or you can revert it yourself. This is a normal part of LLVM development. You can fix your changes and open a new PR to merge them again.

If you don't get any reports, no action is required from you. Your changes are working as expected, well done!

@llvm-ci
Copy link
Collaborator

llvm-ci commented Jul 29, 2025

LLVM Buildbot has detected a new failure on builder lldb-aarch64-ubuntu running on linaro-lldb-aarch64-ubuntu while building lldb at step 6 "test".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/59/builds/21747

Here is the relevant piece of the build log for the reference
Step 6 (test) failure: build (failure)
...
PASS: lldb-api :: commands/memory/write/TestMemoryWrite.py (189 of 2294)
PASS: lldb-api :: commands/platform/basic/TestPlatformPython.py (190 of 2294)
PASS: lldb-api :: commands/platform/file/read/TestPlatformFileRead.py (191 of 2294)
PASS: lldb-api :: commands/platform/file/close/TestPlatformFileClose.py (192 of 2294)
PASS: lldb-api :: commands/memory/read/TestMemoryRead.py (193 of 2294)
PASS: lldb-api :: commands/platform/connect/TestPlatformConnect.py (194 of 2294)
PASS: lldb-api :: commands/platform/process/launch/TestPlatformProcessLaunch.py (195 of 2294)
UNSUPPORTED: lldb-api :: commands/platform/sdk/TestPlatformSDK.py (196 of 2294)
PASS: lldb-api :: commands/platform/process/list/TestProcessList.py (197 of 2294)
UNRESOLVED: lldb-api :: commands/gui/spawn-threads/TestGuiSpawnThreads.py (198 of 2294)
******************** TEST 'lldb-api :: commands/gui/spawn-threads/TestGuiSpawnThreads.py' FAILED ********************
Script:
--
/usr/bin/python3.10 /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/dotest.py -u CXXFLAGS -u CFLAGS --env LLVM_LIBS_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./lib --env LLVM_INCLUDE_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/include --env LLVM_TOOLS_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin --arch aarch64 --build-dir /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex --lldb-module-cache-dir /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex/module-cache-lldb/lldb-api --clang-module-cache-dir /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex/module-cache-clang/lldb-api --executable /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/lldb --compiler /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/clang --dsymutil /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/dsymutil --make /usr/bin/gmake --llvm-tools-dir /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin --lldb-obj-root /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/tools/lldb --lldb-libs-dir /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./lib --cmake-build-type Release /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/commands/gui/spawn-threads -p TestGuiSpawnThreads.py
--
Exit Code: 1

Command Output (stdout):
--
lldb version 22.0.0git (https://github.com/llvm/llvm-project.git revision 9bf3e615a2c6db6e2a00ee2004ebcb21daf1334b)
  clang revision 9bf3e615a2c6db6e2a00ee2004ebcb21daf1334b
  llvm revision 9bf3e615a2c6db6e2a00ee2004ebcb21daf1334b
Skipping the following test categories: ['libc++', 'msvcstl', 'dsym', 'gmodules', 'debugserver', 'objc']

--
Command Output (stderr):
--
FAIL: LLDB (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang-aarch64) :: test_gui (TestGuiSpawnThreads.TestGuiSpawnThreadsTest)
======================================================================
ERROR: test_gui (TestGuiSpawnThreads.TestGuiSpawnThreadsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 149, in wrapper
    return func(*args, **kwargs)
  File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/commands/gui/spawn-threads/TestGuiSpawnThreads.py", line 44, in test_gui
    self.child.expect_exact(f"thread #{i + 2}: tid =")
  File "/usr/local/lib/python3.10/dist-packages/pexpect/spawnbase.py", line 432, in expect_exact
    return exp.expect_loop(timeout)
  File "/usr/local/lib/python3.10/dist-packages/pexpect/expect.py", line 179, in expect_loop
    return self.eof(e)
  File "/usr/local/lib/python3.10/dist-packages/pexpect/expect.py", line 122, in eof
    raise exc
pexpect.exceptions.EOF: End Of File (EOF). Exception style platform.
<pexpect.pty_spawn.spawn object at 0xf8af4d76a1a0>
command: /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/lldb
args: ['/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/lldb', '--no-lldbinit', '--no-use-colors', '-O', 'settings clear --all', '-O', 'settings set symbols.enable-external-lookup false', '-O', 'settings set target.inherit-tcc true', '-O', 'settings set target.disable-aslr false', '-O', 'settings set target.detach-on-error false', '-O', 'settings set target.auto-apply-fixits false', '-O', 'settings set plugin.process.gdb-remote.packet-timeout 60', '-O', 'settings set symbols.clang-modules-cache-path "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex/module-cache-lldb/lldb-api"', '-O', 'settings set use-color false', '-O', 'settings set show-statusline false', '--file', '/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex/commands/gui/spawn-threads/TestGuiSpawnThreads.test_gui/a.out']
buffer (last 100 chars): b''
before (last 100 chars): b'2 0x0000af7077d35030 _start (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/lldb+0x45030)\n'
after: <class 'pexpect.exceptions.EOF'>

@DavidSpickett
Copy link
Collaborator

Ignore that failure, it "fixed" itself.

@llvm-ci
Copy link
Collaborator

llvm-ci commented Jul 29, 2025

LLVM Buildbot has detected a new failure on builder lldb-aarch64-windows running on linaro-armv8-windows-msvc-05 while building lldb at step 6 "test".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/141/builds/10458

Here is the relevant piece of the build log for the reference
Step 6 (test) failure: build (failure)
...
PASS: lldb-unit :: ValueObject/./LLDBValueObjectTests.exe/2/12 (2274 of 2283)
PASS: lldb-unit :: ValueObject/./LLDBValueObjectTests.exe/3/12 (2275 of 2283)
PASS: lldb-unit :: ValueObject/./LLDBValueObjectTests.exe/4/12 (2276 of 2283)
PASS: lldb-unit :: ValueObject/./LLDBValueObjectTests.exe/5/12 (2277 of 2283)
PASS: lldb-unit :: ValueObject/./LLDBValueObjectTests.exe/6/12 (2278 of 2283)
PASS: lldb-unit :: ValueObject/./LLDBValueObjectTests.exe/7/12 (2279 of 2283)
PASS: lldb-unit :: ValueObject/./LLDBValueObjectTests.exe/8/12 (2280 of 2283)
PASS: lldb-unit :: ValueObject/./LLDBValueObjectTests.exe/9/12 (2281 of 2283)
PASS: lldb-unit :: tools/lldb-server/tests/./LLDBServerTests.exe/0/1 (2282 of 2283)
TIMEOUT: lldb-unit :: Host/./HostTests.exe/6/12 (2283 of 2283)
******************** TEST 'lldb-unit :: Host/./HostTests.exe/6/12' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\unittests\Host\.\HostTests.exe-lldb-unit-8148-6-12.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=12 GTEST_SHARD_INDEX=6 C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\unittests\Host\.\HostTests.exe
--

Note: This is test shard 7 of 12.

[==========] Running 8 tests from 6 test suites.

[----------] Global test environment set-up.

[----------] 1 test from FileSystemTest

[ RUN      ] FileSystemTest.FileAndDirectoryComponents

[       OK ] FileSystemTest.FileAndDirectoryComponents (0 ms)

[----------] 1 test from FileSystemTest (0 ms total)



[----------] 1 test from HostInfoTest

[ RUN      ] HostInfoTest.GetAugmentedArchSpec

[       OK ] HostInfoTest.GetAugmentedArchSpec (1 ms)

[----------] 1 test from HostInfoTest (1 ms total)



[----------] 2 tests from MainLoopTest

[ RUN      ] MainLoopTest.ReadPipeObject


--
exit: 15

@DavidSpickett
Copy link
Collaborator

Once that's in, I will rebase my changes on top. I needed to read them through carefully anyway, so I can do both at the same time. I want to be sure I don't drop any Arm/Thumb handling details along the way.

I have rebased those changes to include this and found #151973 along the way. Once that's in I'll put up a PR to port Arm to NativeRegisterContextDBReg.

@b10902118
Copy link
Contributor Author

Thanks! That will be helpful to my arm stuff. I am looking forward to try that.

@DavidSpickett
Copy link
Collaborator

#152284

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.

5 participants