Re: [PATCH 2/7] Handle Windows drives in auto-load script paths

Christian Biesinger
2020-05-26T16:43:14Z

On Tue, May 26, 2020 at 11:40 AM Hannes Domani via Gdb-patches
<gdb-patches@sourceware.org> wrote:
>
> Am Dienstag, 26. Mai 2020, 18:32:38 MESZ hat Christian Biesinger <cbiesinger@google.com> Folgendes geschrieben:
>
> > On Tue, May 26, 2020 at 11:25 AM Hannes Domani via Gdb-patches
> > <gdb-patches@sourceware.org> wrote:
> > >
> > > Am Dienstag, 26. Mai 2020, 18:05:57 MESZ hat Christian Biesinger <cbiesinger@google.com> Folgendes geschrieben:
> > >
> > > > On Mon, May 25, 2020 at 1:57 PM Hannes Domani via Gdb-patches
> > > > <gdb-patches@sourceware.org> wrote:
> > > > >
> > > > > Fixes this testsuite fail on Windows:
> > > > > FAIL: gdb.base/auto-load.exp: print $script_loaded
> > > > >
> > > > > Converts the debugfile path from c:/dir/file to /c/dir/file, so it can be
> > > > > appended to the auto-load path.
> > > >
> > > > How does this work? I thought /c/foo was not supported by either
> > > > cygwin or mingw?
> > >
> > > Yes, but in this case we need a path that can be appended to the various
> > > entries of 'set auto-load scripts-directory'.
> > > c:/foo can't be appended, but /c/foo can.
> > > So you would get something like c:/script/directory/c/foo.
> >
> > OK, so I *think* what you're saying is that if you have an objfile
> > c:\foo\bar.dll, and an auto-load directory c:\load, then with this
> > patch we will look for an auto-load script in
> > c:\load\c\foo\bar.dll-gdb.py? Is that right?
>
> Basically, yes.
>
>
> > If so, shouldn't there be a documentation update about how this works
> > on Windows, and possibly a NEWS entry?
>
> A news entry that the bug was fixed?
> From how I understand gdb.base/auto-load.exp, this is the way it was always
> supposed to work (did I understand this wrong?).

I don't feel so strongly about NEWS, but I specifically meant the
translation of c:\ to c/ on Windows -- shouldn't that be documented?

Christian