Hello,

With the MinGW debugger, it is currently not possible to use a path
that follows the Windows convention.  For instance:

        (gdb) file c:\foo\bar.exe
        c:foobar.exe: No such file or directory.

This is because the routine that parses arguments treats all backslashes
as an escape character.  With a MinGW tool, this does not make sense
when the argument is a path, since the canonical directory separator
on Windows is a backslash...

What the user has to do, at this point, is escape every backslash,
which can be quite painful when the path starts getting longer...

        (gdb) file c:\\foo\\bar.exe
        Reading symbols from c:\foo\bar.exe...done.

What we have done, at AdaCore, is disabling the special nature of
the backslash character when the host is MinGW (we left cygwin alone,
since cygwin users most likely expect a unix-y type of behavior).
It's a incompatible change, and as you'll see with the attached patch,
it changes the behavior for all arguments, not just path names.
Polling the few Windows users we have a AdaCore, they all seem to agree
that they did not expect backslash to be a special character in any
context, so the change seemed right to them.

Before officially submitting this patch for inclusion (including
formal testing), I wanted to see what the feeling towards this sort
of change was...

Note that GDB uses a wrapper around this routine, mostly to add
an out-of-memory exception raised when the routine returns null.
One possible way of achieving the same result, while limiting the
change to GDB alone, would be to modify the gdb_buildargv routine
to escape all backslashes before calling libiberty's buildargv.
But I think that other tools should also consider this change as
beneficial.

-- 
Joel