From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14326 invoked by alias); 3 Mar 2011 17:32:10 -0000 Received: (qmail 14318 invoked by uid 22791); 3 Mar 2011 17:32:08 -0000 X-SWARE-Spam-Status: No, hits=-1.0 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,TW_GB X-Spam-Check-By: sourceware.org Received: from mail-qw0-f41.google.com (HELO mail-qw0-f41.google.com) (209.85.216.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Mar 2011 17:32:04 +0000 Received: by qwd7 with SMTP id 7so1322161qwd.0 for ; Thu, 03 Mar 2011 09:32:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.221.17 with SMTP id ia17mr1241163qcb.6.1299173521065; Thu, 03 Mar 2011 09:32:01 -0800 (PST) Received: by 10.229.89.197 with HTTP; Thu, 3 Mar 2011 09:32:01 -0800 (PST) In-Reply-To: <201103031642.28783.pedro@codesourcery.com> References: <201103031609.43441.pedro@codesourcery.com> <201103031642.28783.pedro@codesourcery.com> Date: Thu, 03 Mar 2011 17:32:00 -0000 Message-ID: Subject: Re: [patch gdb]: Fix some DOS-path related issues in gdb From: Kai Tietz To: Pedro Alves Cc: gdb-patches@sourceware.org, Joel Brobecker , Eli Zaretskii 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/msg00187.txt.bz2 2011/3/3 Pedro Alves : > 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. =A0A Windows build of gdb doesn't have > problems with unix paths. =A0It's a unix gdb that has trouble with > dos paths. That's right from perspective of scanning those file name proper. But well on windows boxes there is also the concept of those drive-letters for volumes. Also (as side-note) the UNC-stuff isn't handled proper for any OS by binutils/gdb/gcc, but well, this is a different story. >> 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. Well, it will help just on Windows boxes, which use same directory-tree on current working drive. But well, it can help. For unix a D: will be still be unresolveable. >> 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), >> + =A0 by default, even if GDB itself is not running on such a system. >> + =A0 Such binaries may contain debug info with source paths the native >> + =A0 path handling functions wouldn't understand (e.g., backslash as >> + =A0 directory separator, drive names, and case insensitivity). =A0The >> + =A0 risk of this going wrong is very minor in practice, so it's more >> + =A0 useful to leave this as default. =A0*/ >> +static const char *source_file_names_mode =3D source_file_names_dos_bas= ed; > > 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. =A099.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. =A0(haven't measured, of course). Well, it is more a matter how and where this filemapping would be handled. I thought about adding this filename layer into libiberty, which then provides the basic file-io routines for filename-conversion. As for relative paths (which are commonly the main-part to be found in debugging information) nothing needs to be done AFAICS. The tricky part are just the absolute paths/filenames. For the case host's and current path match each other (means on windows drive-letter colon, for unix path begins with slash) nothing needs to be done, too. Just the case that absolute-paths don't match needs some actions (and a mapping). This would be best handled on trying to operate on filenames (open,fopen, stat, & co) via a layer provided in libiberty So those mapping can be done on actual access and don't need to be special-cased by app itself. As this issue is present on binutils (bfd), gcc, and gdb, it would be reasonable IMHO to handle this at one common and shared place. By doing this (maybe with some small hashing for transformed names), I wouldn't assume real speed-impact and no serious memory regression. Regards, Kai PS: IA64 PE is another host for which this can occure (wince-arm too, but w= ell).