From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15111 invoked by alias); 4 Mar 2011 07:23:17 -0000 Received: (qmail 15096 invoked by uid 22791); 4 Mar 2011 07:23:16 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_00,TW_GB X-Spam-Check-By: sourceware.org Received: from mail.apical.co.uk (HELO srv1.office.apical.co.uk) (213.106.251.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 Mar 2011 07:23:07 +0000 Received: from [10.250.149.213] (23.nat.acronis.net [91.195.22.23]) (authenticated bits=0) by srv1.office.apical.co.uk (8.14.4/8.14.4) with ESMTP id p247Jp3p011942 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 4 Mar 2011 07:19:53 GMT Message-ID: <4D708E58.6080702@sw.ru> Date: Fri, 04 Mar 2011 07:23:00 -0000 From: Vladimir Simonov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc11 Thunderbird/3.0.4 MIME-Version: 1.0 To: Kai Tietz CC: Pedro Alves , gdb-patches@sourceware.org, Joel Brobecker , Eli Zaretskii Subject: Re: [patch gdb]: Fix some DOS-path related issues in gdb References: <201103031609.43441.pedro@codesourcery.com> <201103031642.28783.pedro@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00273.txt.bz2 On 03/03/2011 08:32 PM, Kai Tietz wrote: > 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. A Windows build of gdb doesn't have >> problems with unix paths. It'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), >>> + 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). > > 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 well). > > Hi all, If the main problem is in mapping absolute DOS paths to Linux ones then the simplest solution is creation appropriate symbolic links on Linux side. I mean that using symlink D: pointed on some directory you can simulate any DOS path. I'm using this approach for many years... Regards Vladimir Simonov