[GPU] GPUActions are ignored on first stop-reply packet fix #46

barsolo2000 · 2025-09-16T00:24:38Z

GPUActions were not handled on the first stop-reply packed that is returned when we launch a process.

Modified the LaunchProcess method to capture and return the first stop-reply packet from the vRun command instead of discarding it. In ProcessGDBRemote::DoLaunch, we now use this captured launch response directly if it's a valid stop-reply packet, so GPU actions in the launch response are processed instead of ignored..

NOTE: It's just fixing the launch case, we also need to follow up and fix the attach and connect cases.

dmpots · 2025-09-16T16:47:23Z

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp

@@ -929,21 +930,22 @@ llvm::Error GDBRemoteCommunicationClient::LaunchProcess(const Args &args) {
      packet.PutStringAsRawHex8(arg.ref());
    }

-    StringExtractorGDBRemote response;
-    if (SendPacketAndWaitForResponse(packet.GetString(), response) !=
+    StringExtractorGDBRemote vrun_response;


I don't think we need to create a separate vrun_response here. We can just pass down the response we take as a parameter to LaunchProcess.

dmpots · 2025-09-16T16:50:18Z

lldb/source/Utility/StringExtractorGDBRemote.cpp

+    return false;
+
+  char first_char = m_packet.empty() ? '\0' : m_packet[0];
+  return first_char == 'T' || first_char == 'S';


Maybe we should add all the packets listed here (e.g. W, X): https://sourceware.org/gdb/current/onlinedocs/gdb.html/Stop-Reply-Packets.html#Stop-Reply-Packets

dmpots · 2025-09-16T16:52:45Z

lldb/test/API/gpu/mock/basic/TestBasicMockGpuPlugin.py

+        self.select_cpu()
+        self.expect(
+            "breakpoint list --internal",
+            substrs=["gpu_first_stop"],


Would be nice to expand this check a bit to show that we have hit the breakpoint

dmpots · 2025-09-16T16:54:15Z

Please run clang-format on this change to make sure it is formatted correctly.

dmpots

LGTM

clayborg · 2025-09-26T18:23:05Z

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp

@@ -916,7 +916,8 @@ lldb::pid_t GDBRemoteCommunicationClient::GetCurrentProcessID(bool allow_lazy) {
  return LLDB_INVALID_PROCESS_ID;
 }

-llvm::Error GDBRemoteCommunicationClient::LaunchProcess(const Args &args) {


We might want to change the return value to:

llvm::Expected<StringExtractorGDBRemote> GDBRemoteCommunicationClient::LaunchProcess(const Args &args);

Then we don't need to pass the StringExtractorGDBRemote &response in as a parameter.

clayborg · 2025-09-26T18:38:38Z

lldb/source/Utility/StringExtractorGDBRemote.cpp

+bool StringExtractorGDBRemote::IsStopReply() const {
+  if (!IsNormalResponse())
+    return false;
+
+  char first_char = m_packet.empty() ? '\0' : m_packet[0];
+  return first_char == 'T' || first_char == 'S' || first_char == 'W' ||
+         first_char == 'X' || first_char == 'w' || first_char == 'N' ||
+         first_char == 'O' || first_char == 'F';
+}
+


I would check for 'T' or 'S' only here. 'W' is for exited, 'X' is for terminated, 'w' is for thread exited, 'N' is for non stop debugging, and 'O' is for output and 'F' is for calling syscalls.

So for using this in a launch scenario, we want to only check for a few. Maybe modifying this to be something like:

FLAGS_ENUM(StopReplyMask) { Signal = (1u << 0), Exited = (1u << 1), Terminated = (1u << 2), Output = (1u << 3), NoResumed = (1u << 4), Syscall = (1u << 5), Any = ((Syscall << 1) - 1u), }; bool StringExtractorGDBRemote::IsStopReply(uint32_t mask) const { if (!IsNormalResponse()) return false; if (mask & Signal && (first_char == 'T' || first_char == 'S')) return true; if (mask & Exited && (first_char == 'w' || first_char == 'W')) return true; if (mask & Terminated && first_char == 'X') return true; if (mask & Output && first_char == 'O') return true; if (mask & NoResumed && first_char == 'N') return true; if (mask & Syscall && first_char == 'F') return true; return false; }

clayborg

Thanks for the changes, looks good!

jeffreytan81 · 2025-10-13T18:05:08Z

lldb/tools/lldb-server/Plugins/MockGPU/LLDBServerPluginMockGPU.cpp

-  BreakpointIDThirdStop = 3,
-  BreakpointIDResumeAndWaitForResume = 4,
-  BreakpointIDWaitForStop = 5
+  BreakpointIDFirstStop = 1,


Is it expected that we added a new BreakpointIDFirstStop but never used in this PR?

My bad. We don't really use it for our testing by as you mentioned below, I accidentally used BreakpointIDThirdStop rather than BreakpointIDFirstStop.

jeffreytan81 · 2025-10-13T18:05:52Z

lldb/tools/lldb-server/Plugins/MockGPU/LLDBServerPluginMockGPU.cpp

+    GPUActions actions;
+    actions.plugin_name = GetPluginName();
+    GPUBreakpointInfo bp;
+    bp.identifier = BreakpointIDThirdStop;


Is this expected? Why the first_time but used 3rd stop id here?

After merging #48 I notice that my test is failing in the upcoming PR: #46. The issue is that having a map of gpu actions with stop_id as a value will create a situation where unique GPUactions that have the same stop_id and name are getting ignored. Having a unique identifier for every gpu action will prevent this situation from happening while still ignoring same gpu action to be executed twice.

dmpots · 2025-10-17T18:09:06Z

lldb/include/lldb/Utility/StringExtractorGDBRemote.h

+    Any = ((Syscall << 1) - 1u),
+  };
+
+  bool IsStopReply() const;


We don't need this overload (and it is not implemented). Just specify the default value in the declaration below.

dmpots · 2025-10-17T18:09:27Z

lldb/source/Utility/StringExtractorGDBRemote.cpp

 }

+bool StringExtractorGDBRemote::IsStopReply(
+    uint32_t mask = StopReplyMask::Any) const {


Default values need to go on the declaration not the definition.

dmpots

LGTM

barsolo2000 marked this pull request as ready for review September 16, 2025 00:26

dmpots requested review from clayborg, dmpots and jeffreytan81 September 16, 2025 16:39

dmpots requested changes Sep 16, 2025

View reviewed changes

barsolo2000 force-pushed the launchFix branch from fd10120 to 7381246 Compare September 16, 2025 20:19

dmpots approved these changes Sep 16, 2025

View reviewed changes

clayborg requested changes Sep 26, 2025

View reviewed changes

barsolo2000 force-pushed the launchFix branch from 7e8a4d5 to c0c7db4 Compare September 30, 2025 20:12

barsolo2000 mentioned this pull request Oct 2, 2025

[AMD][GPU] Undo accidental change in ReadyToSendConnectionRequest #55

Merged

clayborg approved these changes Oct 6, 2025

View reviewed changes

barsolo2000 force-pushed the launchFix branch from 4c1791f to 66dc530 Compare October 8, 2025 21:47

barsolo2000 mentioned this pull request Oct 9, 2025

[GPU] Added identifier for GPU action #60

Merged

jeffreytan81 reviewed Oct 13, 2025

View reviewed changes

Bar Soloveychik added 4 commits October 14, 2025 15:09

GPUActions are ignored on first stop-reply packet fix

2352eec

fixed comments

19c3bb4

fixed test

068f1fa

fixed Jeffrey comment

bc65e24

barsolo2000 force-pushed the launchFix branch from 66dc530 to bc65e24 Compare October 14, 2025 22:28

added correct GPUActions identifer

f1293d0

dmpots requested changes Oct 17, 2025

View reviewed changes

updated isStopReply

af484a5

dmpots changed the title ~~GPUActions are ignored on first stop-reply packet fix~~ [GPU] GPUActions are ignored on first stop-reply packet fix Oct 20, 2025

dmpots approved these changes Oct 20, 2025

View reviewed changes

dmpots merged commit 27a177f into clayborg:llvm-server-plugins Oct 20, 2025
5 checks passed

[GPU] GPUActions are ignored on first stop-reply packet fix #46

[GPU] GPUActions are ignored on first stop-reply packet fix #46

Uh oh!

Conversation

barsolo2000 commented Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dmpots commented Sep 16, 2025

Uh oh!

dmpots left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

clayborg left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dmpots left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

barsolo2000 commented Sep 16, 2025 •

edited

Loading