Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Nikolay Molchanov]

Hello!

I'm looking for a setting that will force gdb 6.5 to print
full file names on Windows in the same format as gdb 6.4
and previous gdb versions. Previously gdb printed messages
like this one:

-break-insert main
^done,bkpt={number="1",type="breakpoint",disp="keep",
enabled="y",addr="0x00401075",func="main",file="t1.c",
fullname="c:/users/nik/t1/t1.c",line="2",times="0"}
           ^^^^^^^^^^^^^^^^^^^^

New version, gdb 6.5, prints fullname using another format:

-break-insert main
^done,bkpt={number="1",type="breakpoint",disp="keep",
enabled="y",addr="0x00401075",func="main",file="t1.c",
fullname="/cygdrive/c/users/nik/t1/t1.c",line="2",times="0"}
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is it a bug or it is an intentional change?
Is there a way to force gdb to print fullname in format,
compatible with gdb 6.4 and previous versions (c:/...)?

Thanks in advance,
Nikolay Molchanov

Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Nick Roberts]

 > I'm looking for a setting that will force gdb 6.5 to print
 > full file names on Windows in the same format as gdb 6.4
 > and previous gdb versions. Previously gdb printed messages
 > like this one:
 > 
 > -break-insert main
 > ^done,bkpt={number="1",type="breakpoint",disp="keep",
 > enabled="y",addr="0x00401075",func="main",file="t1.c",
 > fullname="c:/users/nik/t1/t1.c",line="2",times="0"}
 >            ^^^^^^^^^^^^^^^^^^^^

Is this real output?  I thought the fullname field for breakpoints
was only added in February of this year:

 2006-02-06  Vladimir Prus  <ghost@cs.msu.su>

	 * breakpoint.c (print_one_breakpoint): For MI-like UI, output
	 fullname field.

Could you be confusing it with other output e.g when execution stops:

*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x08048504",func="main",args=[],file="myprog.c",fullname="/home/nickrob/myprog.c",line="57"}

where there has been a fullname field for longer?  After you've set your
breakpoint at main, what output do you get when you do "-exec-run"?


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Daniel Jacobowitz]

On Tue, Aug 08, 2006 at 10:34:46PM +1200, Nick Roberts wrote:
> Is this real output?  I thought the fullname field for breakpoints
> was only added in February of this year:

And what versions of GDB are you really using: where did you get them
from, and what platform are they configured for?

If you build a mingw32 GDB, it'll probably give you c:\\ paths.  A
Cygwin GDB will usually give you /cygdrive paths.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Christopher Faylor]

On Tue, Aug 08, 2006 at 09:18:23AM -0400, Daniel Jacobowitz wrote:
>On Tue, Aug 08, 2006 at 10:34:46PM +1200, Nick Roberts wrote:
>> Is this real output?  I thought the fullname field for breakpoints
>> was only added in February of this year:
>
>And what versions of GDB are you really using: where did you get them
>from, and what platform are they configured for?
>
>If you build a mingw32 GDB, it'll probably give you c:\\ paths.  A
>Cygwin GDB will usually give you /cygdrive paths.

...and that's by design, not by accident.  Cygwin is REALLY intended to
be used with POSIX-like paths.  c:\foo style paths are supported only
as an afterthought.

cgf

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Bob Rossi]

On Tue, Aug 08, 2006 at 11:29:23AM -0400, Christopher Faylor wrote:
> On Tue, Aug 08, 2006 at 09:18:23AM -0400, Daniel Jacobowitz wrote:
> >On Tue, Aug 08, 2006 at 10:34:46PM +1200, Nick Roberts wrote:
> >> Is this real output?  I thought the fullname field for breakpoints
> >> was only added in February of this year:
> >
> >And what versions of GDB are you really using: where did you get them
> >from, and what platform are they configured for?
> >
> >If you build a mingw32 GDB, it'll probably give you c:\\ paths.  A
> >Cygwin GDB will usually give you /cygdrive paths.
> 
> ...and that's by design, not by accident.  Cygwin is REALLY intended to
> be used with POSIX-like paths.  c:\foo style paths are supported only
> as an afterthought.

This seems OK for front ends to GDB that are compiled in Cygwin, and
thus can convert the path /cygpath... to a C:\.. (as is my front end).

However, front ends that compile natively to windows but are using
cygwin's GDB will have trouble with this. Is the intention to exclude
those front ends from understanding this information?

Bob Rossi

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Daniel Jacobowitz]

On Tue, Aug 08, 2006 at 01:31:27PM -0400, Bob Rossi wrote:
> This seems OK for front ends to GDB that are compiled in Cygwin, and
> thus can convert the path /cygpath... to a C:\.. (as is my front end).
> 
> However, front ends that compile natively to windows but are using
> cygwin's GDB will have trouble with this. Is the intention to exclude
> those front ends from understanding this information?

If GDB is a Cygwin application, it will print Cygwin paths.
There's really no way around that and nothing to be done about it.

A non-Cygwin application can convert the Cygwin paths to Windows paths
(by dynamic loading of Cygwin if it's present).  Or use a non-Cygwin
GDB.  I often find the latter easier.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> A non-Cygwin application can convert the Cygwin paths to Windows paths
> (by dynamic loading of Cygwin if it's present).

Interesting idea. How's it done?

I'm not suggesting GDB do such a thing, but it sounds like a useful 
trick for my own purposes.

Andrew

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Daniel Jacobowitz]

On Wed, Aug 09, 2006 at 10:17:13AM +0100, Andrew STUBBS wrote:
> Daniel Jacobowitz wrote:
> >A non-Cygwin application can convert the Cygwin paths to Windows paths
> >(by dynamic loading of Cygwin if it's present).
> 
> Interesting idea. How's it done?

There's an example hidden in the Cygwin sources, in
testsuite/winsup.api/cygload.cc.  It's a little tricksy, but not too
hard.

> I'm not suggesting GDB do such a thing, but it sounds like a useful 
> trick for my own purposes.

It can be, yes :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Christopher Faylor]

On Wed, Aug 09, 2006 at 09:42:09AM -0400, Daniel Jacobowitz wrote:
>On Wed, Aug 09, 2006 at 10:17:13AM +0100, Andrew STUBBS wrote:
>> Daniel Jacobowitz wrote:
>> >A non-Cygwin application can convert the Cygwin paths to Windows paths
>> >(by dynamic loading of Cygwin if it's present).
>> 
>> Interesting idea. How's it done?
>
>There's an example hidden in the Cygwin sources, in
>testsuite/winsup.api/cygload.cc.  It's a little tricksy, but not too
>hard.

It is also documented to some degree here:

http://cygwin.com/faq/faq.programming.html#faq.programming.msvs-mingw

But, of course, now that I have provided a link, I see that it is out of
date.  You need 4212 bytes free at the bottom of the stack, not 4K.  I'm
half-heartedly looking at some way to expose that value to a program
currently.

Further questions or comments about this technique should be directed to
the cygwin mailing list: cygwin AT cygwin PERIOD com

cgf

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Bob Rossi]

On Wed, Aug 09, 2006 at 10:17:13AM +0100, Andrew STUBBS wrote:
> Daniel Jacobowitz wrote:
> >A non-Cygwin application can convert the Cygwin paths to Windows paths
> >(by dynamic loading of Cygwin if it's present).
> 
> Interesting idea. How's it done?
> 
> I'm not suggesting GDB do such a thing, but it sounds like a useful 
> trick for my own purposes.

Of course, don't count on this working. The GDB could easily be built on
Cygwin, and the cygwin1.dll delivered. In this case there will be no
cygpath, and your front end won't work.

Bob Rossi

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Daniel Jacobowitz]

On Wed, Aug 09, 2006 at 02:10:20PM -0400, Bob Rossi wrote:
> On Wed, Aug 09, 2006 at 10:17:13AM +0100, Andrew STUBBS wrote:
> > Daniel Jacobowitz wrote:
> > >A non-Cygwin application can convert the Cygwin paths to Windows paths
> > >(by dynamic loading of Cygwin if it's present).
> > 
> > Interesting idea. How's it done?
> > 
> > I'm not suggesting GDB do such a thing, but it sounds like a useful 
> > trick for my own purposes.
> 
> Of course, don't count on this working. The GDB could easily be built on
> Cygwin, and the cygwin1.dll delivered. In this case there will be no
> cygpath, and your front end won't work.

Please read my suggestion again :-)  It does not rely on a cygpath
binary.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Joel Brobecker]

> Of course, don't count on this working. The GDB could easily be built
> on Cygwin, and the cygwin1.dll delivered. In this case there will be
> no cygpath, and your front end won't work.

Just FYI, and Chris might contradict me, but delivering cygwin1.dll
introduces some issues that are not necessarily easy to overcome.
One of them is compatibility when the end user already has a cygwin
installation present on his system. When that happens, very often
the two will not be able to coexist at the same time and the user
may see error messages saying that the application could not be
loaded because of such issues. We've been able to work around this
problem so far by having the cygwin install and our debugger use
the same one (which one do you choose?), but I think it might be
a risky practice.

-- 
Joel

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Bob Rossi]

On Wed, Aug 09, 2006 at 11:18:19AM -0700, Joel Brobecker wrote:
> > Of course, don't count on this working. The GDB could easily be built
> > on Cygwin, and the cygwin1.dll delivered. In this case there will be
> > no cygpath, and your front end won't work.
> 
> Just FYI, and Chris might contradict me, but delivering cygwin1.dll
> introduces some issues that are not necessarily easy to overcome.
> One of them is compatibility when the end user already has a cygwin
> installation present on his system. When that happens, very often
> the two will not be able to coexist at the same time and the user
> may see error messages saying that the application could not be
> loaded because of such issues. We've been able to work around this
> problem so far by having the cygwin install and our debugger use
> the same one (which one do you choose?), but I think it might be
> a risky practice.

Yes, this is very familiar to me.

  http://sourceware.org/ml/cygwin/2005-03/msg00700.html

I followed the second solution and it worked fine.

Bob Rossi

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Christopher Faylor]

On Wed, Aug 09, 2006 at 11:18:19AM -0700, Joel Brobecker wrote:
>>Of course, don't count on this working.  The GDB could easily be built
>>on Cygwin, and the cygwin1.dll delivered.  In this case there will be
>>no cygpath, and your front end won't work.
>
>Just FYI, and Chris might contradict me, but delivering cygwin1.dll
>introduces some issues that are not necessarily easy to overcome.

Nope.  You are spot on, Joel.  And, thanks for offering independent
verification of this point.

>One of them is compatibility when the end user already has a cygwin
>installation present on his system.  When that happens, very often the
>two will not be able to coexist at the same time and the user may see
>error messages saying that the application could not be loaded because
>of such issues.  We've been able to work around this problem so far by
>having the cygwin install and our debugger use the same one (which one
>do you choose?), but I think it might be a risky practice.

There are issues involved with using two versions of cygwin1.dll on the
same system and they can manifest no matter how much binary editing you
do or source code modification you do.  It is safest to have only the
most recent version on your system.

Cygwin wasn't designed to be distributed as a standalone DLL.  While
you can do that, this practice, like the use of MS-DOS paths is not
something that is guaranteed to work 100% correctly.

cgf

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Joel Brobecker]

> However, front ends that compile natively to windows but are using
> cygwin's GDB will have trouble with this. Is the intention to exclude
> those front ends from understanding this information?

I think that you'll need to add a special case in your front-end
to handle that. Even though GPS is not using cygwin, it does handle
cygwin paths without any problem.

-- 
Joel

Re: Why gdb 6.5 prints fullname in /cygdrive/... format on Windows?

[Nikolay Molchanov]

Joel Brobecker wrote On 08/08/06 10:36,:

>>However, front ends that compile natively to windows but are using
>>cygwin's GDB will have trouble with this. Is the intention to exclude
>>those front ends from understanding this information?
>>    
>>
>
>I think that you'll need to add a special case in your front-end
>to handle that. Even though GPS is not using cygwin, it does handle
>cygwin paths without any problem.
>  
>

Yes, Bob is absolutely right, we have a Java IDE (based on Netbeans),
which is a front end, and it is not easy to translate filenames from
Cygwin format to Windows format. We have to translate them because
Java does not understand Cygwin format. It is easy to translate
"/cygdrive/c/..." to "c:/...", but it is not easy to translate "/tmp/..." or
"/usr/include/..." or any other mounted filesystem path.
Is it possible to add a gdb command or setting to print full name in
Windows format?

Thanks in advance,
Nikolay Molchanov

P.S.: I'm sorry for incorrect gdb 6.4 output in my original mail.
Here is more accurate information.
Previously we used gdb 6.3-50, and it did not print fullname:

$ gdb-6.3.50.exe  --nw --interpreter=mi
~"GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)\n"
~"Copyright 2004 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, and
you are\n"
~"welcome to change it and/or distribute copies of it under certain
conditions.\n"
~"Type \"show copying\" to see the conditions.\n"
~"There is absolutely no warranty for GDB.  Type \"show warranty\" for
details.\n"
~"This GDB was configured as \"i686-pc-cygwin\"."
~"\n"
(gdb)
-file-exec-and-symbols args.exe
^done
(gdb)
-break-insert main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0040106b",func="main",file="src/args.c",line="9",times="0"}
(gdb)
-exec-run
^running
(gdb)
*stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",frame={addr="0x0040106b",func="main",args=[{name="argc",value="1"},{name="argv",value="0x4412b98"}],file="src/args.c",line="9"}
(gdb)
-stack-list-frames
^done,stack=[frame={level="0",addr="0x0040106b",func="main",file="src/args.c",line="9"}]
(gdb)
 
 
--------------------------------------------------------------------------------------------
Now we are trying to use gdb 6.5, which prints fullname (which is great!),
but it is printed in Cygwin format:

$ gdb  --nw --interpreter=mi
~"GNU gdb 6.5.50.20060706-cvs (cygwin-special)\n"
~"Copyright (C) 2006 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, and
you are\n"
~"welcome to change it and/or distribute copies of it under certain
conditions.\n"
~"Type \"show copying\" to see the conditions.\n"
~"There is absolutely no warranty for GDB.  Type \"show warranty\" for
details.\n"
~"This GDB was configured as \"i686-pc-cygwin\"."
~"\n"
(gdb)
-file-exec-and-symbols args.exe
^done
(gdb)
-break-insert main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0040106b",func="main",file="src/args.c",fullname="/cygdrive/c/tmp/nikm/tmp_Projects/Args2/src/args.c",line="9",times="0"}
(gdb)
-exec-run
^running
(gdb)
*stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",frame={addr="0x0040106b",func="main",args=[{name="argc",value="1"},{name="argv",value="0x4412b80"}],file="src/args.c",fullname="/cygdrive/c/tmp/nikm/tmp_Projects/Args2/src/args.c",line="9"}
(gdb)
-stack-list-frames
^done,stack=[frame={level="0",addr="0x0040106b",func="main",file="src/args.c",fullname="/cygdrive/c/tmp/nikm/tmp_Projects/Args2/src/args.c",line="9"}]
(gdb)

Re: Why gdb 6.5 prints fullname in /cygdrive/... format on Windows?

[Daniel Jacobowitz]

On Tue, Aug 08, 2006 at 12:23:46PM -0700, Nikolay Molchanov wrote:
> Is it possible to add a gdb command or setting to print full name in
> Windows format?

I think this would be a very bad idea.  GDB outputs paths in its native
format.  If you're using something with a different native format, why
should GDB have to know about that?

It's not hard to convert.  If you know a path is a Cygwin path, you can
use a standalone program (talk to it over a pipe) that invokes
cygwin_conv_to_windows_path or however it's spelled.


-- 
Daniel Jacobowitz
CodeSourcery

Re: Why gdb 6.5 prints fullname in /cygdrive/... format on Windows?

[Joel Brobecker]

> Is it possible to add a gdb command or setting to print full name in
> Windows format?

IIRC, cygwin provides a program that should do exactly what you want:
cygdrive.

-- 
Joel

Re: Why gdb 6.5 prints fullname in /cygdrive/... format on Windows?

[Pedro Alves]

Joel Brobecker wrote:
>> Is it possible to add a gdb command or setting to print full name in
>> Windows format?
> 
> IIRC, cygwin provides a program that should do exactly what you want:
> cygdrive.
> 

You probably meant cygpath.

 >cygpath -m /cygdrive/c
c:/

Cheers,
Pedro Alves

Re: Why gdb 6.5 prints fullname in /cygdrive/... format on Windows?

[Christopher Faylor]

On Tue, Aug 08, 2006 at 01:01:46PM -0700, Joel Brobecker wrote:
>> Is it possible to add a gdb command or setting to print full name in
>> Windows format?
>
>IIRC, cygwin provides a program that should do exactly what you want:
>cygdrive.

Minor correction -- the program is "cygpath".

FWIW, avoiding MS-DOS paths is one of the main reasons why Cygwin was
invented so *adding* support for MS-DOS paths to Cygwin programs would
be counter to the project's goals.

cgf

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Eli Zaretskii]

> Date: Mon, 07 Aug 2006 23:45:02 -0700
> From: Nikolay Molchanov <Nikolay.Molchanov@Sun.COM>
> 
> I'm looking for a setting that will force gdb 6.5 to print
> full file names on Windows in the same format as gdb 6.4
> and previous gdb versions. Previously gdb printed messages
> like this one:
> 
> -break-insert main
> ^done,bkpt={number="1",type="breakpoint",disp="keep",
> enabled="y",addr="0x00401075",func="main",file="t1.c",
> fullname="c:/users/nik/t1/t1.c",line="2",times="0"}
>            ^^^^^^^^^^^^^^^^^^^^
> 
> New version, gdb 6.5, prints fullname using another format:
> 
> -break-insert main
> ^done,bkpt={number="1",type="breakpoint",disp="keep",
> enabled="y",addr="0x00401075",func="main",file="t1.c",
> fullname="/cygdrive/c/users/nik/t1/t1.c",line="2",times="0"}
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Can you tell what is the file name and the compilation directory
actually recorded in the debug info of the executable?  Do they use
the /cygdrive/c/ form or the c:/ form?

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Nikolay Molchanov]

Eli Zaretskii wrote On 08/08/06 11:53,:

>>Date: Mon, 07 Aug 2006 23:45:02 -0700
>>From: Nikolay Molchanov <Nikolay.Molchanov@Sun.COM>
>>
>>I'm looking for a setting that will force gdb 6.5 to print
>>full file names on Windows in the same format as gdb 6.4
>>and previous gdb versions. Previously gdb printed messages
>>like this one:
>>
>>-break-insert main
>>^done,bkpt={number="1",type="breakpoint",disp="keep",
>>enabled="y",addr="0x00401075",func="main",file="t1.c",
>>fullname="c:/users/nik/t1/t1.c",line="2",times="0"}
>>           ^^^^^^^^^^^^^^^^^^^^
>>
>>New version, gdb 6.5, prints fullname using another format:
>>
>>-break-insert main
>>^done,bkpt={number="1",type="breakpoint",disp="keep",
>>enabled="y",addr="0x00401075",func="main",file="t1.c",
>>fullname="/cygdrive/c/users/nik/t1/t1.c",line="2",times="0"}
>>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>    
>>
>
>Can you tell what is the file name and the compilation directory
>actually recorded in the debug info of the executable?  Do they use
>the /cygdrive/c/ form or the c:/ form?
>
Eli, the executable is built by Cygwin gcc,, but I don't know how to
find out the file name and the compilation directory actually recorded
in the debug info of the executable. Which command prints this info?
 We invoke gcc and gdb from Java IDE, which servers as front end.
And the main problem with file names in Cygwin format is that Java
does not understand such names, so we have to translate them to
Windows format, which is not a trivial task in general case, because
there could be many mounted filesystems, like "/tmp/...",
"/usr/include/..."
and so on.

Thanks,
Nik
.

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Eli Zaretskii]

> Date: Tue, 08 Aug 2006 12:20:36 -0700
> From: Nikolay Molchanov <Nikolay.Molchanov@Sun.COM>
> Cc: gdb@sourceware.org
> 
> Eli, the executable is built by Cygwin gcc,, but I don't know how to
> find out the file name and the compilation directory actually recorded
> in the debug info of the executable. Which command prints this info?

One way that should work is "strings -a foo.exe".  You should see the
name of each of your source files (either with or without a leading
directory) and right after each file name the directory which was the
current when you compiled that file.  Please show both the file names
and the directories that follow them.

> And the main problem with file names in Cygwin format is that Java
> does not understand such names, so we have to translate them to
> Windows format, which is not a trivial task in general case, because
> there could be many mounted filesystems, like "/tmp/...",
> "/usr/include/..."
> and so on.

In general, if you want to avoid such problems, you should be using a
coherent set of tools.  Which in practice means that a Cygwin build
of GDB should be used with Cygwin front ends and other programs.  If
your front end cannot be built with Cygwin, you might consider using
the MinGW GCC and GDB instead, which are native Windows executables
and understand Windows-style d:/foo file names.

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Nikolay Molchanov]

Eli,

>>Date: Tue, 08 Aug 2006 12:20:36 -0700
>>From: Nikolay Molchanov <Nikolay.Molchanov@Sun.COM>
>>Cc: gdb@sourceware.org
>>
>>Eli, the executable is built by Cygwin gcc,, but I don't know how to
>>find out the file name and the compilation directory actually recorded
>>in the debug info of the executable. Which command prints this info?
>>    
>>
>
>One way that should work is "strings -a foo.exe".  You should see the
>name of each of your source files (either with or without a leading
>directory) and right after each file name the directory which was the
>current when you compiled that file.  Please show both the file names
>and the directories that follow them.
>  
>
Yes, it prints the directory with /cygdrive/:

bash-3.1$ strings -a t1-g.exe | grep t1
t1.c
/cygdrive/c/users/nik/t1/

>  
>
>>And the main problem with file names in Cygwin format is that Java
>>does not understand such names, so we have to translate them to
>>Windows format, which is not a trivial task in general case, because
>>there could be many mounted filesystems, like "/tmp/...",
>>"/usr/include/..."
>>and so on.
>>    
>>
>
>In general, if you want to avoid such problems, you should be using a
>coherent set of tools.  Which in practice means that a Cygwin build
>of GDB should be used with Cygwin front ends and other programs.  If
>your front end cannot be built with Cygwin, you might consider using
>the MinGW GCC and GDB instead, which are native Windows executables
>and understand Windows-style d:/foo file names.
>  
>
Yes, we will try to support these compilers as well in future, but our 
primary
target is to provide a free open source IDE for java and C/C++ developers,
and this IDE shall work with Cygwin compilers on Windows, and with many
other compilers on Linux, Windows and Solaris. This IDE is based on Netbeans
(http://netbeans.org), which is a Java application, and it is very 
inconvenient to
translate file names from Cygwin format to Windows format in Java code.
For gdb it takes a few microseconds to translate a file name. We have to
spend 250-400 milliseconds to execute external binary "cygpath -m ..."
and to get translated name from its output. We can try to cache the
directory names, but it is not correct in general case because mount
points can be changed, and there is no way to notice such change
from Java application. So, if it is possible to provide an option to
print fullname in Windows format, we will very much appreciate it.

Thanks,
Nik

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Pedro Alves]

Nikolay Molchanov wrote:
> Eli,
> 
>>> Date: Tue, 08 Aug 2006 12:20:36 -0700
>>> From: Nikolay Molchanov <Nikolay.Molchanov@Sun.COM>
>>> Cc: gdb@sourceware.org
>>>
>>> Eli, the executable is built by Cygwin gcc,, but I don't know how to
>>> find out the file name and the compilation directory actually recorded
>>> in the debug info of the executable. Which command prints this info?
>>>   
>>
>> One way that should work is "strings -a foo.exe".  You should see the
>> name of each of your source files (either with or without a leading
>> directory) and right after each file name the directory which was the
>> current when you compiled that file.  Please show both the file names
>> and the directories that follow them.
>>  
>>
> Yes, it prints the directory with /cygdrive/:
> 
> bash-3.1$ strings -a t1-g.exe | grep t1
> t1.c
> /cygdrive/c/users/nik/t1/
> 
>>  
>>
>>> And the main problem with file names in Cygwin format is that Java
>>> does not understand such names, so we have to translate them to
>>> Windows format, which is not a trivial task in general case, because
>>> there could be many mounted filesystems, like "/tmp/...",
>>> "/usr/include/..."
>>> and so on.
>>>   
>>
>> In general, if you want to avoid such problems, you should be using a
>> coherent set of tools.  Which in practice means that a Cygwin build
>> of GDB should be used with Cygwin front ends and other programs.  If
>> your front end cannot be built with Cygwin, you might consider using
>> the MinGW GCC and GDB instead, which are native Windows executables
>> and understand Windows-style d:/foo file names.
>>  
>>
> Yes, we will try to support these compilers as well in future, but our 
> primary
> target is to provide a free open source IDE for java and C/C++ developers,
> and this IDE shall work with Cygwin compilers on Windows, and with many
> other compilers on Linux, Windows and Solaris. This IDE is based on 
> Netbeans
> (http://netbeans.org), which is a Java application, and it is very 
> inconvenient to
> translate file names from Cygwin format to Windows format in Java code.
> For gdb it takes a few microseconds to translate a file name. We have to
> spend 250-400 milliseconds to execute external binary "cygpath -m ..."
> and to get translated name from its output. We can try to cache the
> directory names, but it is not correct in general case because mount
> points can be changed, and there is no way to notice such change
> from Java application. So, if it is possible to provide an option to
> print fullname in Windows format, we will very much appreciate it.
> 

Hummm, how about?:
You could avoid the external executable loading time everytime you want 
to convert a path, by keeping one "cygpath -m -f -" loaded, and feeding 
it the pathnames to stdin / getting result from stdout.

Cheers,
Pedro Alves

Re: Why gdb 6.5 prints fullname in /cygdrive/... format on Windows?

[Nikolay Molchanov]

Pedro,

>>> Eli Zaretskii  wrote:
>>> In general, if you want to avoid such problems, you should be using a
>>> coherent set of tools.  Which in practice means that a Cygwin build
>>> of GDB should be used with Cygwin front ends and other programs.  If
>>> your front end cannot be built with Cygwin, you might consider using
>>> the MinGW GCC and GDB instead, which are native Windows executables
>>> and understand Windows-style d:/foo file names.
>>>  
>>>
>> Yes, we will try to support these compilers as well in future, but 
>> our primary
>> target is to provide a free open source IDE for java and C/C++ 
>> developers,
>> and this IDE shall work with Cygwin compilers on Windows, and with many
>> other compilers on Linux, Windows and Solaris. This IDE is based on 
>> Netbeans
>> (http://netbeans.org), which is a Java application, and it is very 
>> inconvenient to
>> translate file names from Cygwin format to Windows format in Java code.
>> For gdb it takes a few microseconds to translate a file name. We have to
>> spend 250-400 milliseconds to execute external binary "cygpath -m ..."
>> and to get translated name from its output. We can try to cache the
>> directory names, but it is not correct in general case because mount
>> points can be changed, and there is no way to notice such change
>> from Java application. So, if it is possible to provide an option to
>> print fullname in Windows format, we will very much appreciate it.
>>
>
> Hummm, how about?:
> You could avoid the external executable loading time everytime you 
> want to convert a path, by keeping one "cygpath -m -f -" loaded, and 
> feeding it the pathnames to stdin / getting result from stdout.
>
Thank you, I'll try this solution. In general we are trying to balance 
between
complexity and performance in such cases :-) Dialog seems to be a more
complicated solution, because we don't know what delays can be there,
and what to do in case of timeout (restart cygpath? what if it hangs 
again?).
Also dialog is async, which means we need several threads to "talk" (at 
least
2 threads for stdin and stdout, and probably one more for stderr).
BTW, thank you for the suggestion to use "cygpath -m /..." to translate
file names! I already implemented it, and it works just fine (though the
delays are really visible :-)

Thanks,
Nik

Re: Why gdb 6.5 prints fullname in /cygdrive/... format om Windows?

[Eli Zaretskii]

> Date: Wed, 09 Aug 2006 00:23:18 -0700
> From: Nikolay Molchanov <Nikolay.Molchanov@Sun.COM>
> Cc: gdb@sourceware.org
> 
> >One way that should work is "strings -a foo.exe".  You should see the
> >name of each of your source files (either with or without a leading
> >directory) and right after each file name the directory which was the
> >current when you compiled that file.  Please show both the file names
> >and the directories that follow them.
> >  
> >
> Yes, it prints the directory with /cygdrive/:
> 
> bash-3.1$ strings -a t1-g.exe | grep t1
> t1.c
> /cygdrive/c/users/nik/t1/

If so, there's nothing GDB can do about that: it simply outputs the
source file names as they are recorded in the debug info.

> >In general, if you want to avoid such problems, you should be using a
> >coherent set of tools.  Which in practice means that a Cygwin build
> >of GDB should be used with Cygwin front ends and other programs.  If
> >your front end cannot be built with Cygwin, you might consider using
> >the MinGW GCC and GDB instead, which are native Windows executables
> >and understand Windows-style d:/foo file names.
> >  
> >
> Yes, we will try to support these compilers as well in future, but our 
> primary
> target is to provide a free open source IDE for java and C/C++ developers,
> and this IDE shall work with Cygwin compilers on Windows

The problem is, it's generally not feasible to have Cygwin and
non-Cygwin executables work seamlessly together, and similarly for
MSYS with non-MSYS executables (and UWIN as well, I think).  More
generally, any toolkit that modifies too much the basic OS interface
in order to support Posix features beyond what's available on the
Windows APIs, will always hit this problem sooner or later.

In other words, I think the requirement to support all these compilers
in the same build of the IDE is simply infeasible.  You will probably
be better off if you arrange for your IDE to build as Cygwin and MinGW
applications, and provide both binaries for download.  Then people
could choose the proper binary according to the development tools they
use.  I don;t think there's a reason to believe that someone would
need to mix development tools of different types in the same project.

> So, if it is possible to provide an option to print fullname in
> Windows format, we will very much appreciate it.

That would mean to add code to the native MinGW port that would
understand the Cygwin /cygdrive/ feature.  Such a code will need to
change each time Cygwin changes anything substantial in how this
feature works.  I think such coupling between two unrelated projects
is not a good idea.

How to set a breakpoint in file, which name has spaces?

[Nikolay Molchanov]

Hello!

There seems to be a problem with setting a breakpoint in files,
which names have spaces (usually it happens on Windows, but it
is possible to create such files in Unix filesystems as well).

Here is a part of a log file, that shows the problem.
Note that '\ ' works just great in "-file-exec-and-symbols" command,
but does not work in "-break-insert" command.

bash-3.1$ gdb --nw --interpreter=mi
~"GNU gdb 6.5.50.20060706-cvs (cygwin-special)\n"
~"Copyright (C) 2006 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, and 
you are\n"
~"welcome to change it and/or distribute copies of it under certain 
conditions.\n"
~"Type \"show copying\" to see the conditions.\n"
~"There is absolutely no warranty for GDB.  Type \"show warranty\" for 
details.\n"
~"This GDB was configured as \"i686-pc-cygwin\"."
~"\n"
(gdb)
212-file-exec-and-symbols C:/Documents\ and\ 
Settings/nikm/.netbeans/Netbeans\ Projects/Args1/dist/Debug/args
212^done
(gdb)
221-break-insert C:/Documents\ and\
Settings/nikm/.netbeans/Netbeans\ Projects/Args1/src/main.c:17
&"mi_cmd_break_insert: Garbage following <location>\n"
221^error,msg="mi_cmd_break_insert: Garbage following <location>"
(gdb)

I tried to use single and double quotes, but still no luck.
Is it a known problem? Is there a workaround?

Thanks in advance,
Nikolay Molchanov

Re: How to set a breakpoint in file, which name has spaces?

[Daniel Jacobowitz]

On Wed, Aug 09, 2006 at 11:21:59PM -0700, Nikolay Molchanov wrote:
> Hello!
> 
> There seems to be a problem with setting a breakpoint in files,
> which names have spaces (usually it happens on Windows, but it
> is possible to create such files in Unix filesystems as well).
> 
> Here is a part of a log file, that shows the problem.
> Note that '\ ' works just great in "-file-exec-and-symbols" command,
> but does not work in "-break-insert" command.

Quoting in the MI interface is generally inconsistent.  If you care,
you can find a somewhat more detailed summary of the problems in the
archives a few months ago.

> 221-break-insert C:/Documents\ and\
> Settings/nikm/.netbeans/Netbeans\ Projects/Args1/src/main.c:17
> &"mi_cmd_break_insert: Garbage following <location>\n"
> 221^error,msg="mi_cmd_break_insert: Garbage following <location>"
> (gdb)
> 
> I tried to use single and double quotes, but still no luck.
> Is it a known problem? Is there a workaround?

Let's see.  For current versions of GDB, -break-insert is parsed as a
true MI command, which means it passes through the MI quoting rules.
That's described in the GDB manual (GDB/MI Input Syntax).  It says that
single quotes and backslashes aren't special, only double quotes, and
within double quotes things are treated as a C string.  Then, after
that escaping, it is passed to the normal breakpoint code.

So if you want to simulate:
  break 'C:/Documents and Settings/foo.c':17

You'd need
  -break-insert "'C:/Documents and Settings/foo.c':17"

This is actually more or less how things are supposed to work.

-- 
Daniel Jacobowitz
CodeSourcery

Re: How to set a breakpoint in file, which name has spaces?

[Nikolay Molchanov]

Daniel,

>On Wed, Aug 09, 2006 at 11:21:59PM -0700, Nikolay Molchanov wrote:
>  
>
>>Hello!
>>
>>There seems to be a problem with setting a breakpoint in files,
>>which names have spaces (usually it happens on Windows, but it
>>is possible to create such files in Unix filesystems as well).
>>
>>Here is a part of a log file, that shows the problem.
>>Note that '\ ' works just great in "-file-exec-and-symbols" command,
>>but does not work in "-break-insert" command.
>>    
>>
>
>Quoting in the MI interface is generally inconsistent.  If you care,
>you can find a somewhat more detailed summary of the problems in the
>archives a few months ago.
>  
>
I would be happy to take a look at the discussion.
IMHO a good solution is to use '\ ' to escape spaces. It is standard 
Unix approach.
The real '\' character should be passed as double '\' ("\\").
What is nice, it works just great in "-file-exec-and-symbols" command, 
so it seems
a pretty straight forward solution to make other commands consistent 
with this one.

>  
>
>>221-break-insert C:/Documents\ and\
>>Settings/nikm/.netbeans/Netbeans\ Projects/Args1/src/main.c:17
>>&"mi_cmd_break_insert: Garbage following <location>\n"
>>221^error,msg="mi_cmd_break_insert: Garbage following <location>"
>>(gdb)
>>
>>I tried to use single and double quotes, but still no luck.
>>Is it a known problem? Is there a workaround?
>>    
>>
>
>Let's see.  For current versions of GDB, -break-insert is parsed as a
>true MI command, which means it passes through the MI quoting rules.
>That's described in the GDB manual (GDB/MI Input Syntax).  It says that
>single quotes and backslashes aren't special, only double quotes, and
>within double quotes things are treated as a C string.  Then, after
>that escaping, it is passed to the normal breakpoint code.
>
>So if you want to simulate:
>  break 'C:/Documents and Settings/foo.c':17
>  
>
Unfortunately this does not work:

break 'C:/Documents and Settings/nikm/.netbeans/Netbeans 
Projects/Args1/src/main.c':17
&"break 'C:/Documents and Settings/nikm/.netbeans/Netbeans 
Projects/Args1/src/main.c':17\n"
&"Function \"C:/Documents and Settings/nikm/.netbeans/Netbeans 
Projects/Args1/src/main.c\" not defined.\n"
~"Breakpoint 3 ('C:/Documents and Settings/nikm/.netbeans/Netbeans 
Projects/Args1/src/main.c':17) pending.\n"
^done
(gdb)

>You'd need
>  -break-insert "'C:/Documents and Settings/foo.c':17"
>
>This is actually more or less how things are supposed to work.
>  
>
And this one also does not work:

221-break-insert "'C:/Documents and Settings/nikm/.netbeans/Netbeans 
Projects/Args1/src/main.c':17"
&"Function \"C:/Documents and Settings/nikm/.netbeans/Netbeans 
Projects/Args1/src/main.c\" not defined.\n"
221^done
(gdb)

Re: How to set a breakpoint in file, which name has spaces?

[Daniel Jacobowitz]

On Thu, Aug 10, 2006 at 09:36:35AM -0700, Nikolay Molchanov wrote:
> I would be happy to take a look at the discussion.
> IMHO a good solution is to use '\ ' to escape spaces. It is standard 
> Unix approach.
> The real '\' character should be passed as double '\' ("\\").
> What is nice, it works just great in "-file-exec-and-symbols" command, 
> so it seems
> a pretty straight forward solution to make other commands consistent 
> with this one.

No.  The manual describes the quoting rules that MI is supposed to use;
some commands violate them, but this one doesn't.  It's too late to
change how it's supposed to work now.

> >So if you want to simulate:
> > break 'C:/Documents and Settings/foo.c':17
> > 
> >
> Unfortunately this does not work:

Apparently you need to use double quotes.  I'm not sure why.

> >You'd need
> > -break-insert "'C:/Documents and Settings/foo.c':17"

Which would mean
 -break-insert "\"C:/Documents and Settings/foo.c\":17"

-- 
Daniel Jacobowitz
CodeSourcery

Re: How to set a breakpoint in file, which name has spaces?

[Nikolay Molchanov]

Daniel,

>>>You'd need
>>>-break-insert "'C:/Documents and Settings/foo.c':17"
>>>      
>>>
>
>Which would mean
> -break-insert "\"C:/Documents and Settings/foo.c\":17"
>
>  
>
Thank you very much! This format works!
I hope we will never need to set a breakpoint in a file,
which name has double quotes :-)

Thanks,
Nik

Re: How to set a breakpoint in file, which name has spaces?

[Eli Zaretskii]

> Date: Thu, 10 Aug 2006 22:26:55 -0700
> From: Nikolay Molchanov <Nikolay.Molchanov@Sun.COM>
> Cc: gdb@sourceware.org
> 
> I hope we will never need to set a breakpoint in a file,
> which name has double quotes :-)

MS-Windows filesystems don't allow file names with double quotes, so
you needn't worry about that.

Daniel, should we update the manual in some way, or is this a bug that
should be fixed?

Re: How to set a breakpoint in file, which name has spaces?

[Daniel Jacobowitz]

On Fri, Aug 11, 2006 at 03:55:40PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 10 Aug 2006 22:26:55 -0700
> > From: Nikolay Molchanov <Nikolay.Molchanov@Sun.COM>
> > Cc: gdb@sourceware.org
> > 
> > I hope we will never need to set a breakpoint in a file,
> > which name has double quotes :-)
> 
> MS-Windows filesystems don't allow file names with double quotes, so
> you needn't worry about that.
> 
> Daniel, should we update the manual in some way, or is this a bug that
> should be fixed?

That's a good question :-)  This all comes down to decode_line_1.  The
question of whether to change its parsing or document its quirks is
beyond me, I'm afraid.  I'm reluctant to try touching that code.

I wonder if, for some major version bump, we should document a new
syntax for referring to source locations and implement it from
scratch?

-- 
Daniel Jacobowitz
CodeSourcery

Re: How to set a breakpoint in file, which name has spaces?

[Eli Zaretskii]

> Date: Fri, 11 Aug 2006 09:48:43 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Nikolay.Molchanov@Sun.COM, gdb@sourceware.org
> 
> > Daniel, should we update the manual in some way, or is this a bug that
> > should be fixed?
> 
> That's a good question :-)  This all comes down to decode_line_1.  The
> question of whether to change its parsing or document its quirks is
> beyond me, I'm afraid.  I'm reluctant to try touching that code.

Okay, I will document it, then.

> I wonder if, for some major version bump, we should document a new
> syntax for referring to source locations and implement it from
> scratch?

That sounds like a good idea.  Joel, perhaps you could kindly remind
us about this when ``some major version bump'' will be around the
corner.

Re: How to set a breakpoint in file, which name has spaces?

[Joel Brobecker]

> > I wonder if, for some major version bump, we should document a new
> > syntax for referring to source locations and implement it from
> > scratch?
> 
> That sounds like a good idea.  Joel, perhaps you could kindly remind
> us about this when ``some major version bump'' will be around the
> corner.

I will try to remember. IMO, it wouldn't be a bad idea to design
and implement the new syntax now. We can then decide to do the major
version number bump.

-- 
Joel

Re: How to set a breakpoint in file, which name has spaces?

[Daniel Jacobowitz]

On Fri, Aug 11, 2006 at 01:13:31PM -0700, Joel Brobecker wrote:
> I will try to remember. IMO, it wouldn't be a bad idea to design
> and implement the new syntax now. We can then decide to do the major
> version number bump.

Yes, that's reasonable - although I personally have other priorities,
so maybe for some future version bump :-)

I wrote up a piece about this long ago.  I think we're going to need a
much more precise way of specifying locations: combinations of symbols
in different source languages, shared objects, source files, pathnames,
templates, and different inlining locations make this quite a thorny
problem.

-- 
Daniel Jacobowitz
CodeSourcery

Re: How to set a breakpoint in file, which name has spaces?

[Joel Brobecker]

> > I will try to remember. IMO, it wouldn't be a bad idea to design
> > and implement the new syntax now. We can then decide to do the major
> > version number bump.
> 
> Yes, that's reasonable - although I personally have other priorities,
> so maybe for some future version bump :-)

I know what you mean :-). That's why I suggested working on this first,
whenever that might happen, and then do the version number bump, rather
than having the version number drive when we work on it.

-- 
Joel

Re: How to set a breakpoint in file, which name has spaces?

[Mark Kettenis]

> Date: Fri, 11 Aug 2006 15:55:40 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Thu, 10 Aug 2006 22:26:55 -0700
> > From: Nikolay Molchanov <Nikolay.Molchanov@Sun.COM>
> > Cc: gdb@sourceware.org
> > 
> > I hope we will never need to set a breakpoint in a file,
> > which name has double quotes :-)
> 
> MS-Windows filesystems don't allow file names with double quotes, so
> you needn't worry about that.

But POSIX systems do allow it:

$ touch \"
$ ls -l \"
-rw-r--r--   1 kettenis  kettenis          0 Aug 12 13:41 "

Re: How to set a breakpoint in file, which name has spaces?

[Andreas Schwab]

Mark Kettenis <mark.kettenis@xs4all.nl> writes:

>> Date: Fri, 11 Aug 2006 15:55:40 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>> > Date: Thu, 10 Aug 2006 22:26:55 -0700
>> > From: Nikolay Molchanov <Nikolay.Molchanov@Sun.COM>
>> > Cc: gdb@sourceware.org
>> > 
>> > I hope we will never need to set a breakpoint in a file,
>> > which name has double quotes :-)
>> 
>> MS-Windows filesystems don't allow file names with double quotes, so
>> you needn't worry about that.
>
> But POSIX systems do allow it:

s/POSIX/UNIX/

> $ touch \"
> $ ls -l \"
> -rw-r--r--   1 kettenis  kettenis          0 Aug 12 13:41 "

Just because it is possible does not mean it is useful.  Once you start
using quotes or other meta characters in file names gdb will be the least
of your problems.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: How to set a breakpoint in file, which name has spaces?

[Mark Kettenis]

> From: Andreas Schwab <schwab@suse.de>
> Date: Sat, 12 Aug 2006 14:31:33 +0200
> 
> Mark Kettenis <mark.kettenis@xs4all.nl> writes:
> 
> >> Date: Fri, 11 Aug 2006 15:55:40 +0300
> >> From: Eli Zaretskii <eliz@gnu.org>
> >> 
> >> > Date: Thu, 10 Aug 2006 22:26:55 -0700
> >> > From: Nikolay Molchanov <Nikolay.Molchanov@Sun.COM>
> >> > Cc: gdb@sourceware.org
> >> > 
> >> > I hope we will never need to set a breakpoint in a file,
> >> > which name has double quotes :-)
> >> 
> >> MS-Windows filesystems don't allow file names with double quotes, so
> >> you needn't worry about that.
> >
> > But POSIX systems do allow it:
> 
> s/POSIX/UNIX/
> 
> > $ touch \"
> > $ ls -l \"
> > -rw-r--r--   1 kettenis  kettenis          0 Aug 12 13:41 "
> 
> Just because it is possible does not mean it is useful.  Once you start
> using quotes or other meta characters in file names gdb will be the least
> of your problems.

Sure, but nobody in their right mind would include spaces in their
filenames either.

Mark

Re: How to set a breakpoint in file, which name has spaces?

[Eli Zaretskii]

> Date: Sat, 12 Aug 2006 13:44:05 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: Nikolay.Molchanov@Sun.COM, gdb@sourceware.org
> 
> > Date: Fri, 11 Aug 2006 15:55:40 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > Date: Thu, 10 Aug 2006 22:26:55 -0700
> > > From: Nikolay Molchanov <Nikolay.Molchanov@Sun.COM>
> > > Cc: gdb@sourceware.org
> > > 
> > > I hope we will never need to set a breakpoint in a file,
> > > which name has double quotes :-)
> > 
> > MS-Windows filesystems don't allow file names with double quotes, so
> > you needn't worry about that.
> 
> But POSIX systems do allow it:

Do they also have drive letters?  The original discussion was about
file names such as C:/Documents and Settings/foo.c.

In other words, this whole thread was about Windows file names with
spaces in them.  So POSIX file-name (un)restrictions are not really
relevant.

Re: How to set a breakpoint in file, which name has spaces?

[Mark Kettenis]

> Date: Sat, 12 Aug 2006 17:20:20 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Sat, 12 Aug 2006 13:44:05 +0200 (CEST)
> > From: Mark Kettenis <mark.kettenis@xs4all.nl>
> > CC: Nikolay.Molchanov@Sun.COM, gdb@sourceware.org
> > 
> > > Date: Fri, 11 Aug 2006 15:55:40 +0300
> > > From: Eli Zaretskii <eliz@gnu.org>
> > > 
> > > > Date: Thu, 10 Aug 2006 22:26:55 -0700
> > > > From: Nikolay Molchanov <Nikolay.Molchanov@Sun.COM>
> > > > Cc: gdb@sourceware.org
> > > > 
> > > > I hope we will never need to set a breakpoint in a file,
> > > > which name has double quotes :-)
> > > 
> > > MS-Windows filesystems don't allow file names with double quotes, so
> > > you needn't worry about that.
> > 
> > But POSIX systems do allow it:

Correctling myself, POSIX (EEE Std 1003.1-2001) itself doesn't allow
allow double quotes.

> 
> Do they also have drive letters?  The original discussion was about
> file names such as C:/Documents and Settings/foo.c.

Sigh, the Microsoft employee who came up with the bright idea to put
spaces in standard directory names must have been a complete moron.

Anyway, no they don't have drive names, but C: is a valid filename on
OpenBSD, as are spaces.  So on OpenBSD your example is also a possible
file name.  Of course nobody in their right mind would actually create
such a name on an OpenBSD system.

> In other words, this whole thread was about Windows file names with
> spaces in them.  So POSIX file-name (un)restrictions are not really
> relevant.

Well, I might have missed something, but the discussion also was about
quoting file names in commands, and I really hope you're not
suggesting that we should have seperate quoting rules for Windows and
POSIX-like systems.

Mark