From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SXkyLzUDRWozFyEAWB0awg (envelope-from ) for ; Wed, 01 Jul 2026 08:08:21 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=nBtjGw/k; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id BA7E81E098; Wed, 01 Jul 2026 08:08:21 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A51D81E024 for ; Wed, 01 Jul 2026 08:08:20 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6AD134BA2E0B for ; Wed, 1 Jul 2026 12:08:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6AD134BA2E0B Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=nBtjGw/k Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 749E14BA2E0D for ; Wed, 1 Jul 2026 12:07:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 749E14BA2E0D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 749E14BA2E0D Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782907675; cv=none; b=ZbR+ERzQZ/R8MIMrgR093I63ZGh6qsM1KRCXqBUFDVVgX52PGFZCjlhqIh0VhzQKQDoXAD8Ii5vWa2wzQuBFj/jODH1oPH4hQD5E2zOKqMp82xzifpTvJFthTJq4JmJi+1AdniINHe7tCxrycD7IFonvPNx5fgjfhmlEagbTwjw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782907675; c=relaxed/simple; bh=qYwloEqJcW5ykhSxsgyeDi6sb0PwYkciwj3jnK/jRYI=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=wTmMLln5o7n0B3ffjksBLlBcUwuA9A4ZDrDRTF0YYX2FwYZ5WyCcrjJHume1pVzFgIK5Uw+gY4CFzd4v+0dpDkPUjiDMgJ9L9c523vPeVRSTtUF8kQVZ9WYXk1+ofJ9NzARE64Hc19Cyf/IPKqMUf3K91QG2DCuPniSxpMyvsBg= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=nBtjGw/k DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 749E14BA2E0D Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wetjO-0001LF-3f; Wed, 01 Jul 2026 08:07:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=9Zxh2HJ8y/msvJ3CnzAasvSe4HmK2g9fZ+tlKg6Wx30=; b=nBtjGw/kK/HK ud5Cv2na7CJkVIrqeqXSJbnYyeS7nNcOjE04kbo7Y5qqNIVbfiYVJm6sFxIafaAATSCdq4EHKZhKH oBcCKDYXHWwOKmY99Jva+tZ05EYbJJ2WHG+dP/U8WeG0EKpNwybHSO+NyK1Zd+KTJPnypvxsE6n// 9qYv1r7Shqi2XUwaUcYx1ILCQW4D3HyzSkvhwdKLfnFRBWpPQ4HXz8p5xvMIEOZAjGjuZqA2G1FAM XwNrBkdRC1yaZv3QXkN26JOlzhp/y2Pz5r/IoJZiHr5ySXEstLVIceH9xnBcR3RaLg+p1nNwTdWrI sL/r1VUQuq8xULUwHi5n4w==; Date: Wed, 01 Jul 2026 15:07:50 +0300 Message-Id: <86fr22diax.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: (message from Pedro Alves on Wed, 1 Jul 2026 12:28:41 +0100) Subject: Re: [PATCH v2] Windows: Normalize backward slashes to forward slashes References: <20260629212430.340516-1-pedro@palves.net> <867bnge0bc.fsf@gnu.org> <86qzlocbb4.fsf@gnu.org> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org > Date: Wed, 1 Jul 2026 12:28:41 +0100 > Cc: gdb-patches@sourceware.org > From: Pedro Alves > > 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