This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
2011/3/4 Mark Kettenis<mark.kettenis@xs4all.nl>:Sorry for confusing about C: link.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.
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |