RE: [PATCH] gdb/amdgpu: Fix accessing GPU global memory

["Six, Lancelot" <Lancelot.Six@amd.com>]

AMD General

> -----Original Message-----
> From: Simon Marchi <simark@simark.ca>
> Sent: 08 September 2026 00:30
> To: Pedro Alves <pedro@palves.net>; gdb-patches@sourceware.org
> Cc: Six, Lancelot <Lancelot.Six@amd.com>
> Subject: Re: [PATCH] gdb/amdgpu: Fix accessing GPU global memory
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 2026-09-07 18:15, Pedro Alves wrote:
> > Now that multi solib provider support is in, the gdb.rocm/ tests
> > should work on Windows, in theory.  Turns out they still don't.  GDB
> > is now able to discover GPU code objects, but still fails to stop at
> > GPU breakpoints.
> >
> > The reason is that accessing GPU global memory is not working on
> > Windows.  It fails with STATUS_ERROR_INVALID_LANE_ID, like so:
> >
> >   [amd-dbgapi-lib] amd_dbgapi_code_object_get_info
> (code_object_id=code_object_1
> <"memory://5268#offset=0x90e9850&size=47824">,
> query=CODE_OBJECT_INFO_URI_NAME, value_size=
> > 8, value=0x73739feee0) {
> >   [amd-dbgapi-lib]    callback: allocate_memory (42) {
> >   [amd-dbgapi-lib]    callback: } allocate_memory = 0x1f82fdcc110 (took
> 0.011000 ms)
> >   [amd-dbgapi-lib] } amd_dbgapi_code_object_get_info = STATUS_SUCCESS,
> *value="memory://5268#offset=0x90e9850&size=47824"@000001f82fdcc1
> 10 (took 0.633000 ms)
> >   [amd-dbgapi-lib] amd_dbgapi_read_memory (process_id=process_1,
> wave_id=WAVE_NONE, lane_id=0, address_space_id=address_space_1
> <global>, segment_address=0x90e9850, value_s
> > ize=47824@00000073739fde78, value=0x1f8309246b0) {
> >   [amd-dbgapi-lib] } amd_dbgapi_read_memory =
> STATUS_ERROR_INVALID_LANE_ID (took 0.024000 ms)
> >
> > We get STATUS_ERROR_INVALID_LANE_ID because we passed down
> > AMD_DBGAPI_WAVE_NONE, and in that case dbgapi enforces that the caller
> > pass down AMD_DBGAPI_LANE_NONE for lane.
> >
> > From dbgapi/src/memory.cpp:
> >
> > xfer_memory (amd_dbgapi_process_id_t process_id,
> amd_dbgapi_wave_id_t wave_id,
> > ...
> >   if (wave != nullptr)
> >     {
> >       ...
> >     }
> >   else if (wave_id != AMD_DBGAPI_WAVE_NONE)
> >     {
> >       THROW (AMD_DBGAPI_STATUS_ERROR_INVALID_WAVE_ID);
> >     }
> >   else if (lane_id != AMD_DBGAPI_LANE_NONE)
> >     {
> >       /* wave_id is WAVE_NONE and lane_id != LANE_NONE.  */
> >       THROW (AMD_DBGAPI_STATUS_ERROR_INVALID_LANE_ID);
> <<<<<<<<<< HERE
> >     }
> > ...
> >
> > Actually, all the GPU global accesses currently fail on Linux too!
> > The logs show the exact same STATUS_ERROR_INVALID_LANE_ID all over the
> > place.  It just so happens to be papered over by accident there --
> > when accessing memory via amd-dbgapi-target fails, the core of GDB
> > will try the target beneath in the target stack (the process stratum
> > layer), and that (linux-nat) will work, because unlike on Windows, on
> > Linux we have unified memory so /proc/pid/mem successfully accesses
> > the GPU memory.
> >
> > Fix this by passing AMD_DBGAPI_LANE_NONE when wave_id is
> > AMD_DBGAPI_WAVE_NONE.  We don't have proper lane support yet, so
> when
> > wave_id is a valid wave, continue accessing lane 0.
> >
> > Tested on x86_64-pc-linux-gnu and x86_64-pc-windows-msvc (with
> pending
> > testsuite patches).
> >
> > gdb.rocm/ tests now work on Windows, and most pass cleanly.
> >
> > Change-Id: I7dd53bc0a6ffdfaca71e70772562cc7ac1362f05
> > ---
> >  gdb/amd-dbgapi-target.c | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/gdb/amd-dbgapi-target.c b/gdb/amd-dbgapi-target.c
> > index 45ad8f98a92..93207a8fdd2 100644
> > --- a/gdb/amd-dbgapi-target.c
> > +++ b/gdb/amd-dbgapi-target.c
> > @@ -769,16 +769,20 @@ amd_dbgapi_target::xfer_partial (enum
> target_object object, const char *annex,
> >    amd_dbgapi_wave_id_t wave_id = (ptid_is_gpu (inferior_ptid)
> >                                 ? get_amd_dbgapi_wave_id (inferior_ptid)
> >                                 : AMD_DBGAPI_WAVE_NONE);
> > +  /* dbgapi requires LANE_NONE when wave is WAVE_NONE.  */
> > +  amd_dbgapi_lane_id_t lane_id = (wave_id != AMD_DBGAPI_WAVE_NONE
> > +                               ? 0
> > +                               : AMD_DBGAPI_LANE_NONE);
> >
> >    size_t len = requested_len;
> >    amd_dbgapi_status_t status;
> >
> >    if (readbuf != nullptr)
> > -    status = amd_dbgapi_read_memory (process_id, wave_id, 0,
> > +    status = amd_dbgapi_read_memory (process_id, wave_id, lane_id,
> >                                    AMD_DBGAPI_ADDRESS_SPACE_GLOBAL,
> >                                    offset, &len, readbuf);
> >    else
> > -    status = amd_dbgapi_write_memory (process_id, wave_id, 0,
> > +    status = amd_dbgapi_write_memory (process_id, wave_id, lane_id,
> >                                     AMD_DBGAPI_ADDRESS_SPACE_GLOBAL,
> >                                     offset, &len, writebuf);
>
> I don't know if you want to wait for Lancelot's approval, but fwiw it
> LGTM, and trivial enough.
>
> Approved-By: Simon Marchi <simon.marchi@efficios.com>
>
> Simon

Hi,

This looks good to me as well, nice catch.

Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)

Best,
Lancelot.