Re: [patch gdb]: Fix some DOS-path related issues in gdb

[Vladimir Simonov <sv@sw.ru>]

On 03/03/2011 08:32 PM, Kai Tietz wrote:
> 2011/3/3 Pedro Alves<pedro@codesourcery.com>:
>> 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