gdb: Implement stop-on-solib-events for GPU code objects by amd-bfilipov · Pull Request #235 · ROCm/ROCgdb

amd-bfilipov · 2026-07-27T15:42:37Z

GDB's set stop-on-solib-events 1 setting allows users to stop execution when shared libraries are loaded or
unloaded, enabling inspection and breakpoint placement before library code executes. This feature works for CPU
shared libraries but was not working for GPU code objects loaded by the AMD ROCm runtime.

This PR implements stop-on-solib-events support for GPU code objects, making GPU code object load/unload events
behave consistently with CPU shared library events.

Related: AIROCGDB-589

Root Cause

The amd_dbgapi_target_breakpoint::check_status() function unconditionally set bs->stop = 0 and bs->print_it =
print_it_noop, regardless of the stop_on_solib_events setting. This is in contrast to
internal_breakpoint::check_status() for CPU shared libraries, which respects the setting.

Changes

Implementation:

Added code_object_list_updated flag to amd_dbgapi_inferior_info to track when
AMD_DBGAPI_EVENT_KIND_CODE_OBJECT_LIST_UPDATED events occur
Modified check_status() to check this flag after processing events and update bs->stop, bs->print, and
bs->print_it based on stop_on_solib_events
Set the flag in process_one_event() when CODE_OBJECT_LIST_UPDATED events are seen

Custom message printing:

Implemented print_it() method in amd_dbgapi_target_breakpoint to print a custom message distinguishing GPU code
object events from CPU shared library events
Message format follows the same pattern as CPU events but uses "GPU code object event" instead of "shared
library event"
Lists loaded/unloaded code objects with file:// or memory:// URIs

Testing:

Added test to verify GPU code object events trigger stops when stop-on-solib-events is enabled

Example output with fix applied:

(gdb) set stop-on-solib-events 1
(gdb) run
Starting program: /path/to/simple
Stopped due to shared library event (no libraries added or removed)
(gdb) c
Continuing.
Stopped due to shared library event:
  Inferior loaded /rocm-nightly/lib/libhsa-amd-aqlprofile64.so
(gdb) c
Continuing.
Stopped due to GPU code object event:
  Inferior loaded file:///path/to/simple#offset=8192&size=64008
(gdb) c
Continuing.
Stopped due to GPU code object event:
  Inferior loaded memory://2785254#offset=0x457e30&size=43616
(gdb) c
Continuing.
result is 3
Stopped due to GPU code object event:
  Inferior unloaded file:///path/to/simple#offset=8192&size=64008
(gdb) c
Continuing.
Stopped due to GPU code object event:
  Inferior unloaded memory://2785254#offset=0x457e30&size=43616
(gdb) c
Continuing.
[Inferior 1 (process 2785254) exited normally]

lumachad · 2026-07-29T09:54:36Z

Does this need a review? If so, we need to flip it to review.

amd-bfilipov · 2026-07-29T13:17:19Z

Does this need a review? If so, we need to flip it to review.

Wanted to check some things first, it's ready for review now.

czidev-amd

IMHO, you need to check bs->print_it assign. Any other comment is non blocking.

lumachad · 2026-07-30T09:31:48Z

+      bs->stop = stop_on_solib_events != 0;
+      bs->print = stop_on_solib_events != 0;
+      /* Set print_it to normal so that print_it() method is called.  */
+      bs->print_it = print_it_normal;


"Set print_it to normal so that print_it() method is called." explains the mechanism rather than the intent. A clearer wording would be "Allow print_it() to print the GPU code object event message."

Fixed. Changed comment to: "Allow print_it () to print the GPU code object event message."

lumachad · 2026-07-30T09:31:49Z

+	for {set i 0} {$i < 20} {incr i} {
+	    set test "continue and check for GPU code object event"
+	    gdb_test_multiple "continue" $test {
+		-re "Stopped due to GPU code object event.*Inferior loaded.*\r\n$::gdb_prompt $" {


The test name is a fixed string reused for all 20 iterations of the loop. DejaGnu records each pass and fail by name, so duplicates make the log ambiguous and can hide regressions. Appending $i to the name would fix this, e.g. "continue and check for GPU code object event (iter $i)".

Fixed. Changed test names to be unique per iteration AND per result type using $gdb_test_name

lumachad · 2026-07-30T09:31:49Z

+		}
+		-re ".*\r\n$::gdb_prompt $" {
+		    # Some other stop reason, keep going.
+		    pass $test


The catch-all pattern calls pass for any unrecognised output, including unexpected errors or unknown stop reasons. That means a broken stop reason would be silently recorded as a pass. Consider using fail here instead, or at least adding a timeout arm.

Fixed. Removed the catch-all pattern entirely and added explicit timeout arm that fails

GDB's "set stop-on-solib-events 1" setting was not working for GPU code objects loaded by the AMD ROCm runtime. While CPU shared library events correctly triggered stops when this setting was enabled, GPU code object load events were silently ignored. The root cause was in amd_dbgapi_target_breakpoint::check_status(), which unconditionally set bs->stop = 0 and bs->print_it = print_it_noop, regardless of the stop_on_solib_events setting. This is in contrast to internal_breakpoint::check_status() for CPU shared libraries, which respects the setting by checking the stop_on_solib_events global variable. The fix adds: 1. A code_object_list_updated flag to amd_dbgapi_inferior_info to track when AMD_DBGAPI_EVENT_KIND_CODE_OBJECT_LIST_UPDATED events are seen during process_event_queue(). 2. Logic in check_status() to check this flag after processing events, and update bs->stop, bs->print, and bs->print_it based on stop_on_solib_events. 3. A print_it() override to display "Stopped due to GPU code object event" to distinguish GPU events from CPU shared library events. This makes GPU code object load events behave consistently with CPU shared library events, allowing users to stop execution when GPU code objects are loaded for inspection and breakpoint placement. A test is included in gdb.rocm/solib-event.exp.

lumachad · 2026-07-30T15:58:17Z

@amd-bfilipov When force-pushing, please make a comment clarifying what it is that you changed. Or go through the review comments and clarify for each of those what you've done.

amd-bfilipov · 2026-08-04T13:02:32Z

@amd-bfilipov When force-pushing, please make a comment clarifying what it is that you changed. Or go through the review comments and clarify for each of those what you've done.

@lumachad Understood. Replied to comments.

amd-bfilipov force-pushed the users/bfilipov/fix-solib branch 3 times, most recently from f665745 to 335c12d Compare July 28, 2026 14:55

amd-bfilipov marked this pull request as ready for review July 29, 2026 13:16

amd-bfilipov requested a review from a team as a code owner July 29, 2026 13:16

github-actions Bot assigned lancesix Jul 29, 2026

czidev-amd requested changes Jul 29, 2026

View reviewed changes

Comment thread gdb/testsuite/gdb.rocm/solib-event.exp

Comment thread gdb/amd-dbgapi-target.c Outdated

Comment thread gdb/testsuite/gdb.rocm/solib-event.exp Outdated

Comment thread gdb/testsuite/gdb.rocm/solib-event.exp Outdated

This comment was marked as outdated.

Sign in to view

lumachad requested changes Jul 30, 2026

View reviewed changes

amd-bfilipov force-pushed the users/bfilipov/fix-solib branch from 335c12d to 9dd1ab3 Compare July 30, 2026 15:45

amd-bfilipov force-pushed the users/bfilipov/fix-solib branch from 9dd1ab3 to 79095ea Compare July 30, 2026 15:50

amd-bfilipov requested a review from lumachad July 30, 2026 15:55

aktemur self-assigned this Aug 4, 2026

Uh oh!

Conversation

amd-bfilipov commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lumachad commented Jul 29, 2026

Uh oh!

amd-bfilipov commented Jul 29, 2026

Uh oh!

czidev-amd left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment was marked as outdated.

Uh oh!

Uh oh!

lumachad Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

amd-bfilipov Aug 4, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

lumachad Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

amd-bfilipov Aug 4, 2026

Choose a reason for hiding this comment

Uh oh!

lumachad Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

amd-bfilipov Aug 4, 2026

Choose a reason for hiding this comment

Uh oh!

lumachad commented Jul 30, 2026

Uh oh!

amd-bfilipov commented Aug 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

amd-bfilipov commented Jul 27, 2026 •

edited

Loading