* [PATCH] gdb/amdgpu: Fix accessing GPU global memory
@ 2026-09-07 22:15 Pedro Alves
2026-09-07 23:29 ` Simon Marchi
0 siblings, 1 reply; 3+ messages in thread
From: Pedro Alves @ 2026-09-07 22:15 UTC (permalink / raw)
To: gdb-patches; +Cc: Six, Lancelot
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"@000001f82fdcc110 (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);
base-commit: e0d8f6fc3867435e37e0409987b63e70aee4513b
--
2.54.0
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] gdb/amdgpu: Fix accessing GPU global memory
2026-09-07 22:15 [PATCH] gdb/amdgpu: Fix accessing GPU global memory Pedro Alves
@ 2026-09-07 23:29 ` Simon Marchi
2026-09-08 9:10 ` Six, Lancelot
0 siblings, 1 reply; 3+ messages in thread
From: Simon Marchi @ 2026-09-07 23:29 UTC (permalink / raw)
To: Pedro Alves, gdb-patches; +Cc: Six, Lancelot
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"@000001f82fdcc110 (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
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [PATCH] gdb/amdgpu: Fix accessing GPU global memory
2026-09-07 23:29 ` Simon Marchi
@ 2026-09-08 9:10 ` Six, Lancelot
0 siblings, 0 replies; 3+ messages in thread
From: Six, Lancelot @ 2026-09-08 9:10 UTC (permalink / raw)
To: Simon Marchi, Pedro Alves, gdb-patches
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-09-08 9:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-07 22:15 [PATCH] gdb/amdgpu: Fix accessing GPU global memory Pedro Alves
2026-09-07 23:29 ` Simon Marchi
2026-09-08 9:10 ` Six, Lancelot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox