Fix lookup of separate debug file on MS-Windows.

If you put the separate debug file in a global debug directory, GDB on
MS-Windows would fail to find it.  This happens because we obtain the
directory to look up the debug file by concatenating the debug
directory name with the leading directories of the executable, and the
latter includes the drive letter on MS-Windows.  So we get an invalid
file name like

   d:/usr/lib/debug/d:/usr/bin/foo.debug

This commit fixes that by removing the colon of the drive letter,
thus producing

   d:/usr/lib/debug/d/usr/bin/foo.debug

gdb/ChangeLog:
2019-05-03  Eli Zaretskii  <eliz@gnu.org>

	* symfile.c (find_separate_debug_file): Remove colon from the
	drive spec of DOS/Windows file names of the target, so that the
	file name produced from DEBUGDIR and the target's directory will
	be valid on DOS/Windows systems.

gdb/doc/ChangeLog:
2019-05-03  Eli Zaretskii  <eliz@gnu.org>

	* gdb.texinfo (Separate Debug Files): Document how the
	subdirectory of the global debug directory is computed on
	MS-Windows/MS-DOS.
This commit is contained in:
Eli Zaretskii 2019-05-03 10:29:59 +03:00
parent 41f61c65a2
commit 5f2459c233
4 changed files with 42 additions and 3 deletions

View File

@ -1,3 +1,10 @@
2019-05-03 Eli Zaretskii <eliz@gnu.org>
* symfile.c (find_separate_debug_file): Remove colon from the
drive spec of DOS/Windows file names of the target, so that the
file name produced from DEBUGDIR and the target's directory will
be valid on DOS/Windows systems.
2019-05-02 Andrew Burgess <andrew.burgess@embecosm.com>
* rust-lang.c (val_print_struct): Handle printing structures

View File

@ -1,3 +1,9 @@
2019-05-03 Eli Zaretskii <eliz@gnu.org>
* gdb.texinfo (Separate Debug Files): Document how the
subdirectory of the global debug directory is computed on
MS-Windows/MS-DOS.
2019-04-29 Andrew Burgess <andrew.burgess@embecosm.com>
* gdb.texinfo (Print Settings): Document 'print max-depth'.

View File

@ -20007,9 +20007,13 @@ uses two different methods of looking for the debug file:
@item
For the ``debug link'' method, @value{GDBN} looks up the named file in
the directory of the executable file, then in a subdirectory of that
directory named @file{.debug}, and finally under each one of the global debug
directories, in a subdirectory whose name is identical to the leading
directories of the executable's absolute file name.
directory named @file{.debug}, and finally under each one of the
global debug directories, in a subdirectory whose name is identical to
the leading directories of the executable's absolute file name. (On
MS-Windows/MS-DOS, the drive letter of the executable's leading
directories is converted to a one-letter subdirectory, i.e.@:
@file{d:/usr/bin/} is converted to @file{/d/usr/bin/}, because Windows
filesystems disallow colons in file names.)
@item
For the ``build ID'' method, @value{GDBN} looks in the

View File

@ -1443,11 +1443,33 @@ find_separate_debug_file (const char *dir,
= dirnames_to_char_ptr_vec (debug_file_directory);
gdb::unique_xmalloc_ptr<char> canon_sysroot = gdb_realpath (gdb_sysroot);
/* MS-Windows/MS-DOS don't allow colons in file names; we must
convert the drive letter into a one-letter directory, so that the
file name resulting from splicing below will be valid.
FIXME: The below only works when GDB runs on MS-Windows/MS-DOS.
There are various remote-debugging scenarios where such a
transformation of the drive letter might be required when GDB runs
on a Posix host, see
https://sourceware.org/ml/gdb-patches/2019-04/msg00605.html
If some of those scenarions need to be supported, we will need to
use a different condition for HAS_DRIVE_SPEC and a different macro
instead of STRIP_DRIVE_SPEC, which work on Posix systems as well. */
std::string drive;
if (HAS_DRIVE_SPEC (dir_notarget))
{
drive = dir_notarget[0];
dir_notarget = STRIP_DRIVE_SPEC (dir_notarget);
}
for (const gdb::unique_xmalloc_ptr<char> &debugdir : debugdir_vec)
{
debugfile = target_prefix ? "target:" : "";
debugfile += debugdir.get ();
debugfile += "/";
debugfile += drive;
debugfile += dir_notarget;
debugfile += debuglink;