From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18379 invoked by alias); 3 Mar 2011 16:42:28 -0000 Received: (qmail 18250 invoked by uid 22791); 3 Mar 2011 16:42:26 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_GB,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Mar 2011 16:42:21 +0000 Received: (qmail 16854 invoked from network); 3 Mar 2011 16:42:19 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 Mar 2011 16:42:19 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch gdb]: Fix some DOS-path related issues in gdb Date: Thu, 03 Mar 2011 16:42:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-27-generic; KDE/4.6.0; x86_64; ; ) Cc: Kai Tietz , Joel Brobecker , Eli Zaretskii References: <201103031609.43441.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103031642.28783.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/msg00180.txt.bz2 On Thursday 03 March 2011 16:19:41, Kai Tietz wrote: > Yes, sorry. I read it now. Well, this flag sounds on first hand > proper, but by rethinking it a bit, it is not working. > If you have compiled your application via cross-compiler on unix for a > target with a different file-system schema (like windows), and then > try to debug it via an native debugger, you will see that filenames > and paths won't work at all. It's supposed to work, because the "dos-based" setting accepts unix style paths as well. A Windows build of gdb doesn't have problems with unix paths. It's a unix gdb that has trouble with dos paths. > This is caused by the fact, that debugging information always are > using host's (and not target's) filename schema. The patch I pointed at is precisely supposed to help with that scenario. > So to have here a > command-line switch won't solve anything AFAICS. The patches leaves gdb being lax in filename comparisions by default, even on unix. > +/* Handle binaries compiled on DOS-based filesystems (e.g, Windows), > + by default, even if GDB itself is not running on such a system. > + Such binaries may contain debug info with source paths the native > + path handling functions wouldn't understand (e.g., backslash as > + directory separator, drive names, and case insensitivity). The > + risk of this going wrong is very minor in practice, so it's more > + useful to leave this as default. */ > +static const char *source_file_names_mode = source_file_names_dos_based; If you have a bizarre case where you really need strict case-sensitive filename comparisions, and to handle `\' in filenames, then you'd need to flip the switch. 99.9999999999% of the users won't. > IMHO the only valid approach to solve this is: > a) Assume that gbd uses internally always its host-filename-schema > (this is my patch about) > b) Introduce a mapping of foreign file-systems to host's, which can be > setuped by user. This is likely to be more memory consuming, and likely to introduce a hit in debug info read time. (haven't measured, of course). > Sadly this can't be detected by debugging-information > as AFAIK it lacks this information to tell on what host it was build. Yeah. -- Pedro Alves