RE: [PATCH] gdb/amdgpu: Handle SIGABRT with a higher priority than SIGTRAP

AMD General

Hi Lancelot,

On Thursday, August 6, 2026 12:24 AM, Six, Lancelot wrote:
> On the AMDGPU target, waves (known as threads by GDB) can report
> multiple events at the same time.  However, the amd-dbgapi-target can
> only report one target_waitstatus to the core of GDB.  This means that
> when multiple exceptions are reported at once, the target needs to
> choose which one is the most important.
>
> In the current implementation, if we single step the instruction which
> should cause a STOP_REASON_ABORT, the target only reports the single
> step (GDB_SIGNAL_TRAP), missing the abort signal (GDB_SIGNAL_ABRT).
> However, when single stepping an abort, we expert SIGABRT to be shown to

Typo: expert -> expect

> the user.
>
> This patch proposes to change the priority in the target so
> STOP_REASON_ASSERT_TRAP takes priority over STOP_REASON_SINGLE_STEP and
> other debugger related traps such as watchpoint.
>
> Add a testcase which have GDB single step a simple shader until it calls
> abort ().  Before this patch, we had:
>
>     (gdb) x/3i $pc
>     => 0x7ffff7fa9600 <_Z4kernv>:   s_sleep 8
>        0x7ffff7fa9604 <_Z4kernv+4>: s_trap 2    # The abort instruction
>        0x7ffff7fa9608:      v_illegal
>     (gdb) si
>     0x00007ffff7fa9604 in kern() () from file:///.../step-abort#offset=8192&size=3296
>     (gdb) si
>     0x00007ffff7fa9608 in ?? ()
>     (gdb) si
>
>     Thread 5 "kern" received signal SIGILL, Illegal instruction.
>     0x00007ffff7fa960c in ?? ()
>
> GDB would single step over the s_trap 2 instruction, but silently hide
> the SIGABRT, trying to execute past the end of the shader.  With this
> patch, GDB correctly recognises the abort:
>
>     (gdb) si
>     0x00007ffff7fa9604 in kern() ()
>        from file:///.../step-abort#offset=8192&size=3296
>     (gdb) si
>
>     Thread 5 "kern" received signal SIGABRT, Aborted.
>     0x00007ffff7fa9608 in ?? ()
>
> Since the SIGABRT is now correctly reported to GDB, the next continue
> will be able to resume the thread with the appropriate signal, notifying
> the runtime that the queue where the shader was running is now in the
> error state.
>
> Tested on x86_64-linux + AMDGPU gfx1031.

Looks good to me.  Thanks.
Reviewed-By: Tankut Baris Aktemur <[email protected]>

-Baris