This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch gdb]: Fix some DOS-path related issues in gdb
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