This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Why gdb 6.5 prints fullname in /cygdrive/... format on Windows?
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