[binutils-gdb] gdb/solib-rocm: add support for file URI on Windows

Lancelot SIX via Gdb-cvs <[email protected]> Wed, 27 May 2026 10:28:31 +0000 (GMT)
Newsgroups gmane.comp.gdb.cvs
Message-ID <[email protected]>
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d623dadc2c4ecd509359015ae5a1ac856ba89b05

commit d623dadc2c4ecd509359015ae5a1ac856ba89b05
Author: Lancelot Six <[email protected]>
Date:   Wed May 20 18:22:56 2026 +0100

    gdb/solib-rocm: add support for file URI on Windows
    
    For processes using the ROCm runtime, GPU code objects are reported to
    the debugger in the form of a URI (those are available to GDB using the
    amd_dbgapi_process_code_object_list function and query the
    AMD_DBGAPI_CODE_OBJECT_INFO_URI_NAME property).  Each URI can be of 2
    forms:
      - "memory://$PID/mem#offset=$ADDR&size=$SIZE"
      - "file://$PATH#offset=$OFFSET&size=$SIZE"
    
    On the Windows platform, only the "memory" URI form is used at the
    moment, but future runtime changes might make it report code objects
    using the "file" form.  When using the "file" form, when the runtime
    reports an absolute path, the URI will look something like this:
    
        file:///C:/foo/bar/file.exe#offset=0x123&size=0x321
    
    The decoding scheme currently implemented in
    gdb/solib-rocm:rocm_bfd_iovec_open would extract the file path as
    "/C:/foo/bar/file.exe", and will eventually hand this path to
    solib_open.
    
    Surprisingly enough, solib_open still manages to locate the file
    properly.  This is due to the following of code which effectively drops
    the leading "/" turning the path into a valid absolute path which can
    eventually be opened.
    
        /* If the search in gdb_sysroot failed, and the path name is
           absolute at this point, make it relative.  (openp will try and open the
           file according to its absolute path otherwise, which is not what we want.)
           Affects subsequent searches for this solib.  */
        if (found_file < 0 && IS_TARGET_ABSOLUTE_PATH (fskind, in_pathname))
          {
            /* First, get rid of any drive letters etc.  */
            while (!IS_TARGET_DIR_SEPARATOR (fskind, *in_pathname))
              in_pathname++;
    
            /* Next, get rid of all leading dir separators.  */
            while (IS_TARGET_DIR_SEPARATOR (fskind, *in_pathname))
              in_pathname++;
          }
    
    This patch proposes to fix rocm_solib so we properly decode the file
    path and give a valid path to solib_open to properly support this
    scheme.
    
    Note that this patch only looks for forward slashes "/" in the pattern
    matching and not the traditional backslashes (as IS_TARGET_DIR_SEPARATOR
    would) as URIs use forward slashes, not backslashes.
    
    Current GDB does not really AMDGPU debugging on Windows (there are still
    a couple of missing necessary pieces), but this patch can still be
    applied upstream and will eventually be needed.  I have tested this
    patch on top of the downstream ROCgdb windows branch[1].  I have also
    tested this patch on Linux + gfx1031 on top of master to ensure this
    causes no regression.
    
    [1] https://github.com/ROCm/ROCgdb/tree/amd-temp-windows
    
    Approved-By: Pedro Alves <[email protected]>
    Change-Id: I10a1a32167007d5613e5a8696918bad5438285f3

Diff:
---
 gdb/solib-rocm.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/gdb/solib-rocm.c b/gdb/solib-rocm.c
index d9ae4294c98..38904b9633c 100644
--- a/gdb/solib-rocm.c
+++ b/gdb/solib-rocm.c
@@ -30,6 +30,7 @@
 #include "solib.h"
 #include "solib-svr4.h"
 #include "symfile.h"
+#include "filesystem.h"
 
 namespace {
 
@@ -586,6 +587,22 @@ rocm_bfd_iovec_open (bfd *abfd, inferior *inferior)
 
       if (protocol == "file")
 	{
+	  /* A Windows absolute file path is encoded in a file: URI with a
+	     leading "/" before the drive letter: "file:///C:/Users/foo/bar".
+	     See grammar in RFC 8089 Section 2, the path-absolute production
+	     requires the leading "/".  'path-absolute' is defined by RFC 3986
+	     Section 3.3.  After decoding, decoded_path would be
+	     "/C:/Users/foo/bar", which is not a valid Windows path.  Drop the
+	     leading "/" as a normalization step.  */
+	  if ((effective_target_file_system_kind ()
+	       == file_system_kind_dos_based)
+	      && decoded_path.length () >= 4
+	      && decoded_path[0] == '/'
+	      && c_isalpha (decoded_path[1])
+	      && decoded_path[2] == ':'
+	      && decoded_path[3] == '/')
+	    decoded_path.erase (0, 1);
+
 	  auto info = get_solib_info (inferior);
 	  fileio_error target_errno;
 	  target_fd fd = info->fd_cache.open (decoded_path, &target_errno);