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

[Kai Tietz <ktietz70 at googlemail dot com>]

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).