On 03/05/2011 12:13 PM, Kai Tietz wrote: > 2011/3/4 Mark Kettenis: >>> Date: Fri, 4 Mar 2011 10:48:35 +0100 >>> From: Kai Tietz >>> >>> 2011/3/3 Eli Zaretskii: >>>>> Date: Thu, 3 Mar 2011 18:58:32 +0400 >>>>> From: Joel Brobecker >>>>> Cc: Kai Tietz, 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