public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@efficios.com>
To: Christian Biesinger <cbiesinger@google.com>
Cc: gdb-patches <gdb-patches@sourceware.org>, Eli Zaretskii <eliz@gnu.org>
Subject: Re: [PATCH] testsuite: use cygpath to convert from Unix to Windows paths
Date: Wed, 11 Mar 2020 15:09:10 -0400	[thread overview]
Message-ID: <b44ee23f-5ba6-ba52-bd3d-9584fc091b56@efficios.com> (raw)
In-Reply-To: <CAPTJ0XHvyrOEjHNj2eeOECNCB6a-E1VmzCuptT30RicgDLeHJw@mail.gmail.com>

On 2020-03-11 2:40 p.m., Christian Biesinger wrote:
>> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
>> index 9614e8dc87cd..ac16e0e85c99 100644
>> --- a/gdb/testsuite/lib/gdb.exp
>> +++ b/gdb/testsuite/lib/gdb.exp
>> @@ -4899,8 +4899,10 @@ proc standard_output_file {basename} {
>>      file mkdir $dir
>>      # If running on MinGW, replace /c/foo with c:/foo
>>      if { [ishost *-*-mingw*] } {
>> -        set dir [regsub {^/([a-z])/} $dir {\1:/}]
>> +       set dir [exec cygpath --mixed "${dir}"]
> 
> This is fine, but out of curiosity, why --mixed instead of --windows?

--mixed produces paths with forward slashes:

  C:/hello/christian

rather than back slashes:

  C:\hello\christian

And the backslashes wreak havoc (we would need to escape them):

  C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot open output file C:msys64homesmarchi^Huild^Hinutils-gdbgdb  estsuiteoutputsgdb.archi386-bp_permanent/i386-bp_permanent.exe: Invalid argument

Since the tools understand forward slashes, it's just easier to use that.

> 
>> +
>>      }
> 
> Why the empty line above?

A leftover from fighting with Windows, I'll make sure to remove it.

However, the solution I proposed won't work with the non-MinGW-w64 MinGW, as
it does not ship with cygpath.  Here is another version of the patch that uses
`pwd -W` to get the same information.


From b1da3b3b78b92887eeed61b72ca765be45ce3ce2 Mon Sep 17 00:00:00 2001
From: Simon Marchi <simon.marchi@efficios.com>
Date: Wed, 11 Mar 2020 14:16:17 -0400
Subject: [PATCH] testsuite: use `pwd -W` to convert from Unix to Windows paths

When on a MinGW host, standard_output_file uses a regular expression to
convert Unix-style paths of the form "/c/foo" to "c:/foo".  This is
needed because the paths we pass to GDB (for example, with the "file"
command) need to be in the Windows form.

However, the regexp only works if your binutils-gdb repo is under a
`/[a-z]/...` path (the Unix paths mapping to Windows drives).
Presumably, that works if you clone the repo in Windows, then access it
through `/c/...`.

In my case, I've cloned the repository directly inside my MinGW shell,
so in /home/smarchi.  The regexp therefore doesn't work for me.  The
path doesn't get transformed, and the file command fails when running
any test:

    (gdb) file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent
    /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent: No such file or directory.

A safer way to do this is to execute `pwd -W` while in the directory we
want the path for, this is what this patch does.

I have also considered using the using the cygpath utility to do the
conversion.  It can be used to convert any MinGW path into its Windows
equivalent.  Despite originally coming from Cygwin, the cygpath utility
is distributed by MinGW-w64 and can be used in that environment.
However, it's not distributed with the non-MinGW-w64 MinGW.

The `pwd -W` trick only works with directories that exist, which is the
case here, so it's sufficient.

With this, the file command in the test succeeds:

    (gdb) file C:/msys64/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent
    Reading symbols from C:/msys64/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent...

gdb/testsuite/ChangeLog:

	* lib/gdb.exp (standard_output_file): Use `pwd -W` to convert
	from Unix to Windows path.
---
 gdb/testsuite/lib/gdb.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 9614e8dc87cd..9e903ba34776 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -4899,7 +4899,7 @@ proc standard_output_file {basename} {
     file mkdir $dir
     # If running on MinGW, replace /c/foo with c:/foo
     if { [ishost *-*-mingw*] } {
-        set dir [regsub {^/([a-z])/} $dir {\1:/}]
+        set dir [exec sh -c "cd ${dir} && pwd -W"]
     }
     return [file join $dir $basename]
 }
-- 
2.25.1


  reply	other threads:[~2020-03-11 19:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 18:32 Simon Marchi
2020-03-11 18:40 ` Christian Biesinger
2020-03-11 19:09   ` Simon Marchi [this message]
2020-03-11 19:14     ` Eli Zaretskii
2020-03-11 19:26       ` Simon Marchi
2020-03-13 17:57         ` Tom Tromey
2020-03-13 18:14           ` Christian Biesinger
2020-03-13 19:11           ` Tom Tromey
2020-05-12 22:44             ` Simon Marchi

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=b44ee23f-5ba6-ba52-bd3d-9584fc091b56@efficios.com \
    --to=simon.marchi@efficios.com \
    --cc=cbiesinger@google.com \
    --cc=eliz@gnu.org \
    --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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).