From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23082 invoked by alias); 9 Mar 2011 13:36:03 -0000 Received: (qmail 22987 invoked by uid 22791); 9 Mar 2011 13:36:02 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Mar 2011 13:35:57 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LHS00300LN04700@a-mtaout20.012.net.il>; Wed, 09 Mar 2011 15:35:54 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.124.58.59]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LHS002W3LRRHH30@a-mtaout20.012.net.il>; Wed, 09 Mar 2011 15:35:53 +0200 (IST) Date: Wed, 09 Mar 2011 13:54:00 -0000 From: Eli Zaretskii Subject: Re: [patch libiberty include]: Add additional helper functions for directory-separator searching In-reply-to: <201103091258.38655.pedro@codesourcery.com> To: Pedro Alves Cc: gdb-patches@sourceware.org, dj@redhat.com, ktietz70@googlemail.com, binutils@sourceware.org, gcc-patches@gcc.gnu.org Reply-to: Eli Zaretskii Message-id: <83lj0opgav.fsf@gnu.org> References: <201103091146.36746.pedro@codesourcery.com> <83pqq0pj4b.fsf@gnu.org> <201103091258.38655.pedro@codesourcery.com> 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/msg00595.txt.bz2 > From: Pedro Alves > 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.