From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1067 invoked by alias); 12 Oct 2009 20:45:01 -0000 Received: (qmail 1059 invoked by uid 22791); 12 Oct 2009 20:45:00 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 12 Oct 2009 20:44:54 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 6790910CF8; Mon, 12 Oct 2009 20:46:40 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 317D610B94; Mon, 12 Oct 2009 20:46:40 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1MxRlD-0004rM-O0; Mon, 12 Oct 2009 16:44:51 -0400 Date: Mon, 12 Oct 2009 20:45:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: Danny Backx , gdb-patches Subject: Re: shared lib dos filename style - one more question Message-ID: <20091012204451.GA17607@caradoc.them.org> Mail-Followup-To: Joel Brobecker , Danny Backx , gdb-patches References: <1253973110.10921.76.camel@pavilion> <1254946075.10921.178.camel@pavilion> <20091007201145.GA21557@caradoc.them.org> <1255017831.10921.197.camel@pavilion> <20091009173650.GB5272@adacore.com> <1255114781.10921.217.camel@pavilion> <20091010021849.GC5272@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091010021849.GC5272@adacore.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2009-10/txt/msg00249.txt.bz2 On Fri, Oct 09, 2009 at 07:18:49PM -0700, Joel Brobecker wrote: > My thoughts on that are similar to Daniel's: I don't think that we'll > see many files on UNIX systems that start with d: or d:\, nor will we > see a lot of backslashes either. But you never know, people like to > shoot themselves in the foot, I've noticed. > > I would agree to changing GDB so that pathnames are treated as DOS > pathnames, modulo the case-sensitivity issue. This means that d:/ > or d:\ is treated as a drive, and that forward and backward slashes > are treated as directory separators. I don't think we want to start > treating filenames as case-insensitive on Unix systems. > > But I think that this should still remain under control of a setting > that allows GDB to revert to using the host filesystem convention. > That way, if we run into unexpected issues, we can tell a user how > to get back to the previous behavior. > > Another venue that I don't think we have explored, is to fix the problem > locally in solib:solib_find. Have we considered enhancing it in a way > that, if solib_find found nothing, then call it again, but with a > Unix-ified path. If the file happens to be the in solib search path, > it should be able to locate and return it. There's nothing straightforward that this latter approach could do for case-sensitivity problems, though - is there? I'd prefer not to completely rule out handling this case. I wonder if the best solution wouldn't be a tri-state setting, defaulting to 'auto' - DOS style on DOS/Windows hosts, also recognizing forward slashes; Unix style on Unix hosts, also recognizing drive letters and backslashes. I haven't thought entirely about the pain involved in supporting wrong-case files. Maybe this is just wrong-headed... if open failed, we'd have to do a wrong-case search, and that could get seriously out of hand. So maybe this is nuts... Anyway, I'd prefer a global solution rather than one local to solib_find. For instance, we've had trouble with FILENAME_CMP depending on which host the program was *compiled* on. That's right, compiled. It doesn't always matter what the host or target systems are. -- Daniel Jacobowitz CodeSourcery