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

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

> 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