Re: [patch gdb]: Fix some DOS-path related issues in gdb

[Kai Tietz <ktietz70@googlemail.com>]

2011/3/4 Mark Kettenis <mark.kettenis@xs4all.nl>:
>> Date: Fri, 4 Mar 2011 10:48:35 +0100
>> From: Kai Tietz <ktietz70@googlemail.com>
>>
>> 2011/3/3 Eli Zaretskii <eliz@gnu.org>:
>> >> Date: Thu, 3 Mar 2011 18:58:32 +0400
>> >> From: Joel Brobecker <brobecker@adacore.com>
>> >> Cc: Kai Tietz <ktietz70@googlemail.com>, gdb-patches@sourceware.org
>> >>
>> >> > I didn't know that the Windows 64bit target can use ELF debug info.
>> >> > Can it?  With what toolchains?
>> >> >
>> >> > As for mdebugread.c, I always thought it was MIPS specific.  What
>> >> > other platforms use it?
>> >>
>> >> These would still be pertinent in the case of cross debugging, no?
>> >> If the files were cross-compiled on Windows, the debug info would
>> >> contain file paths that follow the Windows convention...
>> >
>> > Is that use-case even practical?  Who would develop on Windows if they
>> > have Linux or Irix?
>> >
>> > Anyway, if others don't mind to have DOS-ism in mdebugread.c and
>> > elfread.c, I don't object.
>> >
>>
>> I didn't saw here direct objections. So ok for apply?
>>
>> On a second thought about Pedros's switch for turning on
>> case-(in)sensitive-ness by switch, it could be helpful. But the
>> slash/backslash issue is something pretty incompatible. Windows host
>> don't have issues in general (not for all API) to use slash and
>> backslash, but on unix filesystem a backslash causes troubles. So we
>> need here some path/filename normalization.
>
> There is no problem with backslashes in path names on Unix-like
> systems.  Backslashes don't have a special meaning; they're just like
> normal letters.  That's exactly why a native debugger on a Unix-like
> system should not try to be DOS compatible at all.  And if you ask me,
> the same is true for a cross-debugger for a Unix-like target running
> on a Unix-like host.

I didn't said that backslashes are forbidden characters in
file/directory names, I just mentioned that they are causing problems.
And well, you provided here the best example. A referenced filename -
eg. 'C:\source\xyz.c" - would be treated on Unix-like filesystem as
one file name and it wouldn't be an absolute path at all. How a user
should be able to match such a thing? Symbolic links (as suggested
before) won't work.
Even worse it gets by the second example provided by André in his
post. As here on a linux based OS the file "..\\calendar\\main.cpp"
directory "C:\\SDK1\\Examples\\4.7\\richtext\\calendar-build-desktop/".
So if gdb should be able to debug a native application, which might be
cross-compiled on a different host with a different file-system, the
is for sure a lot of work.
Nevertheless my patch didn't addressed that.It just fixes the obvious
bug in file-comparision on Windows-like filesystems. It won't change
behavior on Unix-like OS AFAICS.


Kai