This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]