Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: gdb-patches@sourceware.org
Cc: Pedro Alves <pedro@palves.net>
Subject: [PATCH 3/4] gdb/amd-dbgapi-target: Update xfer_partial to always use dbgapi
Date: Fri,  8 May 2026 18:53:37 +0100	[thread overview]
Message-ID: <20260508175338.536044-4-pedro@palves.net> (raw)
In-Reply-To: <20260508175338.536044-1-pedro@palves.net>

From: Lancelot SIX <lancelot.six@amd.com>

On the Windows platform, the entire "global" address space is not
mapped in the inferior memory.  For such configuration, part of the
global address space lives in GPU memory, and can only be accessed via
rocm-dbgapi.

This patch updates amd_dbgapi_target::xfer_partial so it always calls
into amd-dbgapi to access the global address space.  GDB will still be
called to access host memory using xfer_global_memory callback.

To be sure that the callback request is not routed back to dbgapi, the
xfer_global_memory callback is modified to route the request to
whichever target sits below the amd-dbgapi target on the target stack.

Co-Authored-By: Pedro Alves <pedro@palves.net>
---
This is mostly Lancelot's work.  I mainly tweaked the comments a bit
for clarity, and added a new comment to
amd_dbgapi_xfer_global_memory_callback, based on info from the commit
log.

Change-Id: I2d5ca46edf65e2dec3606d18f7ad1d22d0275a63
commit-id: 2e4a1e78
---
 gdb/amd-dbgapi-target.c | 43 +++++++++++++++++++++++++++++++++++------
 1 file changed, 37 insertions(+), 6 deletions(-)

diff --git a/gdb/amd-dbgapi-target.c b/gdb/amd-dbgapi-target.c
index 60013301c10..caa3b32b9d6 100644
--- a/gdb/amd-dbgapi-target.c
+++ b/gdb/amd-dbgapi-target.c
@@ -695,9 +695,31 @@ amd_dbgapi_target::xfer_partial (enum target_object object, const char *annex,
 {
   std::optional<scoped_restore_current_thread> maybe_restore_thread;
 
-  if (!ptid_is_gpu (inferior_ptid))
-    return beneath ()->xfer_partial (object, annex, readbuf, writebuf, offset,
-				     requested_len, xfered_len);
+  /* We want to handle most of the memory requests using amd_dbgapi.
+     This is because on Windows, memory allocated on the GPUs cannot
+     be accessed using the Win32 ReadProcessMemory/WriteProcessMemory
+     calls, in the Windows native target (windows_nat_target).  Even
+     if the current thread is a host thread, we might still need to
+     access some memory on the GPU, for example to access code objects
+     loaded on the device to place breakpoints.
+
+     For everything that is available on the host address space,
+     amd_dbgapi uses the amd_dbgapi_xfer_global_memory_callback
+     callback to do the xfer operation, which calls into whatever is
+     beneath us on the target stack.
+
+     There is one case where we do not want to use dbgapi to perform
+     the memory operations: when removing breakpoints from the child
+     process after a fork.  When this happens, the child does not have
+     an inferior of its own, so instead current_inferior() refers to
+     the parent, and inferior_ptid has the child's PTID.  We can use
+     the parent's process_stratum_target (the one below us) to do the
+     memory operation, but dbgapi knows nothing about the child and
+     would try to update the parent's memory.  */
+  if ((!ptid_is_gpu (inferior_ptid) && object != TARGET_OBJECT_MEMORY)
+      || inferior_ptid.pid () != current_inferior ()->pid)
+    return beneath ()->xfer_partial (object, annex, readbuf, writebuf,
+				     offset, requested_len, xfered_len);
 
   gdb_assert (requested_len > 0);
   gdb_assert (xfered_len != nullptr);
@@ -707,7 +729,9 @@ amd_dbgapi_target::xfer_partial (enum target_object object, const char *annex,
 
   amd_dbgapi_process_id_t process_id
     = get_amd_dbgapi_process_id (current_inferior ());
-  amd_dbgapi_wave_id_t wave_id = get_amd_dbgapi_wave_id (inferior_ptid);
+  amd_dbgapi_wave_id_t wave_id = (ptid_is_gpu (inferior_ptid)
+				  ? get_amd_dbgapi_wave_id (inferior_ptid)
+				  : AMD_DBGAPI_WAVE_NONE);
 
   size_t len = requested_len;
   amd_dbgapi_status_t status;
@@ -2485,9 +2509,16 @@ amd_dbgapi_xfer_global_memory_callback
   set_current_inferior (inf);
   set_current_program_space (inf->pspace);
 
+  /* To ensure that the callback request is not routed back to dbgapi,
+     route the request to whichever target sits below the amd-dbgapi
+     target on the target stack.  */
+  target_ops *handler = (inf->target_is_pushed (&the_amd_dbgapi_target)
+			 ? inf->find_target_beneath (&the_amd_dbgapi_target)
+			 : inf->top_target ());
+
   target_xfer_status status
-    = target_xfer_partial (inf->top_target (), TARGET_OBJECT_RAW_MEMORY,
-			   nullptr, static_cast<gdb_byte *> (read_buffer),
+    = target_xfer_partial (handler, TARGET_OBJECT_RAW_MEMORY, nullptr,
+			   static_cast<gdb_byte *> (read_buffer),
 			   static_cast<const gdb_byte *> (write_buffer),
 			   global_address, *value_size, value_size);
 
-- 
2.53.0


  parent reply	other threads:[~2026-05-08 17:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-08 17:53 [PATCH 0/4] AMD GPU debugging support on Windows Pedro Alves
2026-05-08 17:53 ` [PATCH 1/4] gdb/amd-dbgapi-target: Move Linux code to amd-dbagapi-posix-hdep.c Pedro Alves
2026-05-08 17:53 ` [PATCH 2/4] gdb/amd-dbgapi-target: Add amd-dbgapi-mingw-hdep.c for Windows Pedro Alves
2026-05-08 17:53 ` Pedro Alves [this message]
2026-05-08 17:53 ` [PATCH 4/4] gdb/NEWS: Add note about AMD GPU debugging on Windows Pedro Alves
2026-05-08 18:29   ` Eli Zaretskii
2026-06-12 13:39 ` [PATCH 0/4] AMD GPU debugging support " Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260508175338.536044-4-pedro@palves.net \
    --to=pedro@palves.net \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox