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

> Date: Tue, 08 Aug 2006 12:20:36 -0700
> From: Nikolay Molchanov <Nikolay.MolchanovSun.COM>
> Cc: gdbsourceware.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.

Eli,

>>Date: Tue, 08 Aug 2006 12:20:36 -0700
>>From: Nikolay Molchanov <Nikolay.MolchanovSun.COM>
>>Cc: gdbsourceware.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

Nikolay Molchanov wrote:
> Eli,
> 
>>> Date: Tue, 08 Aug 2006 12:20:36 -0700
>>> From: Nikolay Molchanov
<Nikolay.MolchanovSun.COM>
>>> Cc: gdbsourceware.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

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

> Date: Wed, 09 Aug 2006 00:23:18 -0700
> From: Nikolay Molchanov <Nikolay.MolchanovSun.COM>
> Cc: gdbsourceware.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.

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

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

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

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)

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