Re: [gdb/libiberty] Improve support for cross debugging shared libraries with DOS style pathnames (from Unix hosts)

[Eli Zaretskii <eliz@gnu.org>]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Thu, 22 Apr 2010 18:24:26 +0100
> 
> The fix is to teach GDB about the distintion between host
> paths and target paths, and make the target file system
> "kind" selectable at run time.  See the new target_lbasename,
> IS_TARGET_DIR_SEPARATOR, IS_TARGET_ABSOLUTE_PATH,
> HAS_TARGET_DRIVE_SPEC in the patch (gdb side).
> 
> For that, the patch introduces a new set/show command pair
> so the user can tweak the target's file system flavour, in
> case GDB gets it wrong:

Thanks!

>  (gdb) help set target-file-system-kind
>  Set assumed file system kind for target reported paths

Please don't use "path" when you really mean "file name".  It's
confusing; "path" should be reserved for lists of directories such as
PATH or INFOPATH.

> --- src.orig/gdb/solib.c	2010-04-22 17:19:42.000000000 +0100
> +++ src/gdb/solib.c	2010-04-22 17:22:34.000000000 +0100
> @@ -104,6 +104,76 @@ The search path for loading non-absolute
>  		    value);
>  }
>  
> +/* Handle DOS-like target reported paths, that is for example, DLL
> +   paths like c:\sys\bin\foo.dll (drive name, backslash as dir
> +   separator), even if GDB itself is not running on such a system.  */
> +
> +static const char target_file_system_kind_auto[] = "auto";
> +static const char target_file_system_kind_unix[] = "unix";
> +static const char target_file_system_kind_dos_based[] = "dos-based";
> +static const char *target_file_system_kinds[] =
> +{
> +  target_file_system_kind_auto,
> +  target_file_system_kind_unix,
> +  target_file_system_kind_dos_based
> +};

Is it wise to define these in solib.c?  What about ports that don't
link solib.c into the binary?

I'd suggest to move this (and the related functions) to some more
general source file, even if for now these facilities are used only
for shared library lookup.

> +  /* If the search in gdb_sysroot failed, and the path name has a
> +     drive spec (e.g, c:/foo), try stripping ':' from the drive spec,
> +     and retrying in the sysroot:
> +       c:/foo/bar.dll ==> /sysroot/c/foo/bar.dll.  */

Why not /sysroot/foo/bar, without the "c" part?  What systems are set
up the way this code expects?

> Index: src/gdb/i386-cygwin-tdep.c
> ===================================================================
> --- src.orig/gdb/i386-cygwin-tdep.c	2010-04-22 17:19:42.000000000 +0100
> +++ src/gdb/i386-cygwin-tdep.c	2010-04-22 17:22:34.000000000 +0100
> @@ -235,6 +235,10 @@ i386_cygwin_init_abi (struct gdbarch_inf
>      (gdbarch, windows_core_xfer_shared_libraries);
>  
>    set_gdbarch_auto_wide_charset (gdbarch, i386_cygwin_auto_wide_charset);
> +
> +  /* Canonical paths on this target look like `c:\Program Files\Foo App\mydso.dll',
> +     for example.  */
> +  set_gdbarch_has_dos_based_file_system (gdbarch, 1);
>  }

Any reasons not to provide similar settings for MinGW and DJGPP?

> +* Support for remote debugging Windows and SymbianOS shared libraries
> +  from Unix hosts has been improved.

Is this feature really used only for remote debugging?  Doesn't it
affect native debugging as well?

> +@smallexample
> +  c:\foo\bar.dll ==> c:/foo/bar.dll
> +@end smallexample

Please use @result{} instead of the ASCII art.

> +@kindex set target-file-system-kind (unix|dos-based|auto)
> +@kindex show target-file-system-kind
> +@item set target-file-system-kind @var{kind}
> +Set assumed file system kind for target reported paths.

This warrants some @cindex entry, preferably including "dos" as its
substring.  Something like

  @cindex DOS file-name semantics if file names.

Again, please don't use "path" instead of "file name" (here and
elsewhere).

The NEWS entry and the patch for the manual are okay with the above
changes.

Thanks.