From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9359 invoked by alias); 12 Mar 2011 16:40:54 -0000 Received: (qmail 9332 invoked by uid 22791); 12 Mar 2011 16:40:53 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-qy0-f169.google.com (HELO mail-qy0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 12 Mar 2011 16:40:47 +0000 Received: by qyk2 with SMTP id 2so418355qyk.0 for ; Sat, 12 Mar 2011 08:40:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.141.71 with SMTP id l7mr8743817qcu.44.1299948045257; Sat, 12 Mar 2011 08:40:45 -0800 (PST) Received: by 10.229.89.197 with HTTP; Sat, 12 Mar 2011 08:40:45 -0800 (PST) In-Reply-To: <83lj0opgav.fsf@gnu.org> References: <201103091146.36746.pedro@codesourcery.com> <83pqq0pj4b.fsf@gnu.org> <201103091258.38655.pedro@codesourcery.com> <83lj0opgav.fsf@gnu.org> Date: Sat, 12 Mar 2011 22:59:00 -0000 Message-ID: Subject: Re: [patch libiberty include]: Add additional helper functions for directory-separator searching From: Kai Tietz To: Eli Zaretskii Cc: Pedro Alves , gdb-patches@sourceware.org, dj@redhat.com, binutils@sourceware.org, gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00695.txt.bz2 2011/3/9 Eli Zaretskii : >> From: Pedro Alves >> Date: Wed, 9 Mar 2011 12:58:38 +0000 >> Cc: gdb-patches@sourceware.org, >> =A0dj@redhat.com, >> =A0ktietz70@googlemail.com, >> =A0binutils@sourceware.org, >> =A0gcc-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. =A0The 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. =A0If 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. =A0Could you >> > elaborate? =A0And what "couple of coff and mdebug readers" did you have >> > in mind? >> >> Sorry, in the hurry, I had a (another) brain cramp. =A0Wouldn't break. >> Still it'd be useless to change this _if_ gcc hardcodes '/'. =A0Dunno >> whether it does. > > At least on MinGW, GCC simply uses whatever was passed on the command > line. =A0I tested that by compiling the same source file, passing it to > GCC with different flavors of slashes, including mixed ones. =A0Then 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: > > =A0(gdb) info sources > =A0Source files for which symbols have been read in: > > > > =A0Source files for which symbols will be read in on demand: > > =A0d:/usr/eli/data/dbw.c, d:\usr\eli/data\dbw.c > > This is with GDB 7.2 and GCC 3.4.2. =A0That means we compare files with > strcmp/strcasecmp somewhere, and don't know that / and \ are > equivalent here. =A0Or 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