This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch libiberty include]: Add additional helper functions for directory-separator searching
2011/3/9 Eli Zaretskii <eliz@gnu.org>:
>> From: Pedro Alves <pedro@codesourcery.com>
>> Date: Wed, 9 Mar 2011 12:58:38 +0000
>> Cc: gdb-patches@sourceware.org,
>> ?dj@redhat.com,
>> ?ktietz70@googlemail.com,
>> ?binutils@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.
Yes, this observation is related to some comparision tweaks in libcpp
and in some other parts in gcc about filenames. When gcc gets into
stage 1, I will post the prepared patch for this.
Kai