> 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.