Re: [PATCH v2] Windows: Normalize backward slashes to forward slashes

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 1 Jul 2026 12:28:41 +0100
> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> 
> Still, I think the conversion is worth doing.  What the slash direction does
> for sure affect is the argv[0] the inferior sees.  The command line we hand
> CreateProcess is also what the child's CRT splits into argv, so without converting,
> the inferior sees forward slashes in its own program name.  Giving the inferior
> native separators in argv[0] seems like enough reason to convert -- i.e., not
> framing it about what CreateProcess parses, but what the inferior itself sees
> and parses.

I agree.

> I've made gdb and gdbserver do that, and added a comment about this.  In gdb/windows-nat.c:
> 
>   /* Convert the executable path to backslash separators, so the
>      inferior observes native backslashes in its own program name.  */
>   std::string toexec_native = exec_file;
>   std::replace (toexec_native.begin (), toexec_native.end (), '/', '\\');
>   toexec = toexec_native.c_str ();
> 
> and in gdbserver/win32-low.cc:
> 
>   /* Convert the executable path to backslash separators, so the
>      inferior observes native backslashes in its own program name.  */
>   std::string program_native = program;
>   std::replace (program_native.begin (), program_native.end (), '/', '\\');
>   program = program_native.c_str ();
> 
> 
> (Note: these are both on !Cygwin paths, as the Cygwin paths already do the path
> conversion via cygwin_conv_path.  And BTW, Cygwin GDB already presented forward
> slashes to users already everywhere, including in "info shared", etc.)
> 
> 
> Having this reason written down also avoids having to try to come up with some
> speculative comment about some old Windows behavior we're not exactly sure what it was.
> 
> 
> > 
> >> If it's really a problem on supported Windows versions, it should be a matter of converting back to forward slashes before we
> >> call CreateProcess.  We already do that in gdb/windows-nat.c:windows_nat_target::create_inferior, for "set cwd":
> >>
> >>       /* Mirror slashes on inferior's cwd.  */
> >>       std::replace (expanded_infcwd.begin (), expanded_infcwd.end (),
> >> 		    '/', '\\');
> >>
> >> we'd just need to do the same for exec_file.
> > 
> > Yes, I think it's safer to convert to all backslashes in the argument
> > we pass to CreateProcess.  And it will not show outside of that place,
> > so the (very positive and welcome) effects of your changes will not be
> > affected.
> > 
> 
> Here's the updated patch.  Other than the tweaks mentioned above, and an updated
> commit log, nothing else changed.
> 
> Let me know what you think.

LGTM, thanks.  I have a couple of minor comments below.

> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -83,6 +83,21 @@
>  
>  * Support for native Thread Local Storage (TLS) variables on Windows.
>  
> +* GDB now normalizes backslashes to forward slashes on Windows.
> +
> +  E.g., depending on compiler and build system used by your project,
> +  previously GDB could show a mix of slash styles, like for example:
> +
> +     C:/proj/src\main.c
> +
> +  GDB will now consistently show forward slashes:
> +
> +     C:/proj/src/main.c
> +
> +  This affects everywhere GDB shows a filename/dirname: source
> +  filenames, executable filename, shared libraries, the cd/pwd
> +  commands, etc.

Should this mention GDB/MI output?  Someone might not guess that it's
covered by "etc.", given that the other examples are from quite
different use cases.

> +char *
> +normalize_slashes (char *path)
> +{
> +  for (char *p = path; *p != '\0'; ++p)
> +    if (*p == '\\')
> +      *p = '/';
> +  return path;
> +}

Ehm... GNU Coding Standards frown on using "path" for anything but
PATH-style directory lists.  So maybe we should use "filename" or
somesuch, here and elsewhere.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>