> From: Pedro Alves <pe...@codesourcery.com> > Date: Wed, 9 Mar 2011 12:58:38 +0000 > Cc: gdb-patc...@sourceware.org, > d...@redhat.com, > ktiet...@googlemail.com, > binut...@sourceware.org, > gcc-patches@gcc.gnu.org > > > > The one's left are: 1 in a linux-native only file (never cares > > > for other filesystem semantics), and a couple in the coff and > > > mdebug readers. The latter could be rewritten in terms of > > > lbasename, but I'm not sure whether gcc outputs a literal '/' in > > > that case even when building on mingw. If so, and we changed them, > > > we'd be breaking reading these files on Windows > > > > Sorry, I don't understand how would that break on Windows. Could you > > elaborate? And what "couple of coff and mdebug readers" did you have > > in mind? > > Sorry, in the hurry, I had a (another) brain cramp. Wouldn't break. > Still it'd be useless to change this _if_ gcc hardcodes '/'. Dunno > whether it does.
At least on MinGW, GCC simply uses whatever was passed on the command line. I tested that by compiling the same source file, passing it to GCC with different flavors of slashes, including mixed ones. Then in GDB I typed "info sources" and saw the source file with exactly the same flavor of slashes as what I typed on the GCC command line. Funnily enough, when the file name given to GCC includes at least one backslash, "info sources" shows the same file twice, like this: (gdb) info sources Source files for which symbols have been read in: Source files for which symbols will be read in on demand: d:/usr/eli/data/dbw.c, d:\usr\eli/data\dbw.c This is with GDB 7.2 and GCC 3.4.2. That means we compare files with strcmp/strcasecmp somewhere, and don't know that / and \ are equivalent here. Or maybe it's a bug in the ancient version of GCC I use.
