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

[Vladimir Simonov <sv at sw dot 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

Attachment: gcc-dosbase.patch
Description: Text document

Attachment: gcc-4.4.2-filename-normalize.patch
Description: Text document