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

[Kai Tietz <ktietz70@googlemail.com>]

2011/3/5 Vladimir Simonov <sv@sw.ru>:
> On 03/05/2011 12:13 PM, Kai Tietz wrote:
>>
>> 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.
>
> Sorry for confusing about C: link.
>
> Yes, I've met the same problem several
> years ago. The solution was - fix original names on Windows side.
> For Windows names 'C:\source\xyz.c" and  'C:/source/xyz.c" are absolutely
> equivalent. If we replace "\\" with "/" in gcc command line,
> debug info will have records like C:/source/xyz.c
>
> Probably gcc-dosbase it is not needed - gcc command may
> converted by some external filter...
>
> With this patches all should be ok. I mean C: link or directory
> in current WD should work
>
> Best regards
> Vladimir Simonov
>

Yes, this patch at least avoids issues about written out
file-information.  But of course it doesn't touch the comparision
problematic itself. There are in gcc still a lot of issues about
file-comparisions and directory separators. Btw your patch looks
suitable for normalization from windows -> unix like file-system, but
not for vice-verse, as you are using here libiberties path-separator
macros, which are itself host dependent.

I prepared for gcc already a patch-set for addressing native-filename
comparision, but well, stage-4 doesn't look suitable for this.

Regards,
Kai