From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31588 invoked by alias); 15 May 2008 18:55:48 -0000 Received: (qmail 31542 invoked by uid 22791); 15 May 2008 18:55:34 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout6.012.net.il (HELO mtaout6.012.net.il) (84.95.2.16) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 15 May 2008 18:55:15 +0000 Received: from HOME-C4E4A596F7 ([83.130.255.47]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K0X006FZBW2UXG2@i-mtaout6.012.net.il> for gdb-patches@sources.redhat.com; Thu, 15 May 2008 22:09:39 +0300 (IDT) Date: Thu, 15 May 2008 19:30:00 -0000 From: Eli Zaretskii Subject: Re: [RFC] new substitute path when loading feature In-reply-to: <20080515160551.GA24101@caradoc.them.org> X-012-Sender: halo1@inter.net.il To: Daniel Jacobowitz Cc: aristovski@qnx.com, gdb-patches@sources.redhat.com Reply-to: Eli Zaretskii Message-id: References: <20080513190818.GA13776@caradoc.them.org> <4829E7DA.3010606@qnx.com> <20080513192041.GA14593@caradoc.them.org> <20080515160551.GA24101@caradoc.them.org> 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: 2008-05/txt/msg00479.txt.bz2 > Date: Thu, 15 May 2008 12:05:51 -0400 > From: Daniel Jacobowitz > Cc: Eli Zaretskii > > On Tue, May 13, 2008 at 03:20:41PM -0400, Daniel Jacobowitz wrote: > > On Tue, May 13, 2008 at 03:11:22PM -0400, Aleksandar Ristovski wrote: > > > No, this particular issue is not because of the slashes, but rather > > > due to IS_ABSOLUTE_PATH returning false on a path like "c:/Temp...". > > > > OK. I think I "fixed" FILENAME_CMP and not IS_ABSOLUTE_PATH, but it > > would not be hard to do both. > > > > I'll try to post something tonight. > > Sorry, my existing patch was a mess so I had to rewrite it. I haven't > really tested this; it doesn't break a native Linux GDB in any case > that I consider significant. See the comments in defs.h and utils.c > for the details. > > Does this fix the same problem you're working on? Does anyone see a > problem with the compromises I made here? Eli, I'd appreciate your > opinion. Well, the patch will certainly work with DOS-ish file names on a Posix host, but I'm worried about breaking file names that are perfectly valid on Posix filesystems, but which just happen to use colons and backslashes. I agree that a probability of meeting such file names on Posix platforms is miniscule, but this patch leaves the user no fire escape whatsoever when she does meet them. Can we please augment this with some minimal band-aid for when backslashes and colons are literally used in a file name? Something like a user option to disable this feature and use normal Posix file-name syntax? I figure this would be enough, since mixing object files compiled on Posix and Windows platforms should be _really_ rare. > +/* Compare two filenames. This version should be used instead of > + FILENAME_CMP for filenames from debug information; it recognizes > + equivalences from compiling on a DOS filesystem even if the > + debugger is running on a POSIX host. */ > + > +int > +gdb_filename_cmp (const char *lhs, const char *rhs) > +{ > + for (; *lhs || *rhs; lhs++, rhs++) > + { > +#ifndef HAVE_DOS_BASED_FILE_SYSTEM > + /* When debugging on a POSIX host, assume that each filename was > + recorded with a single consistent capitalization during > + compilation. Source trees are too likely to contain both > + main.c and Main.c. */ > + if (*lhs == *rhs) > + continue; > +#else > + if (tolower (*lhs) == tolower (*rhs)) > + continue; > +#endif > + > + if (*lhs == '/' && *rhs == '\\') > + continue; > + if (*lhs == '\\' && *rhs == '/') > + continue; > + return (int) *lhs - (int) *rhs; > + } > + return 0; > +} Will this work if the file name is encoded in UTF-8 or some other multi-byte encoding, btw? We do want to support those, don't we?