From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25531 invoked by alias); 22 Apr 2019 09:19:34 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 25298 invoked by uid 89); 22 Apr 2019 09:19:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.1 spammy=aware, U*simark, symfile.c, dir_notarget X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 22 Apr 2019 09:19:32 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37744) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIV6o-0007uK-Js; Mon, 22 Apr 2019 05:19:30 -0400 Received: from [176.228.60.248] (port=4402 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hIV6o-0002oZ-2U; Mon, 22 Apr 2019 05:19:30 -0400 Date: Mon, 22 Apr 2019 09:19:00 -0000 Message-Id: <835zr68kiw.fsf@gnu.org> From: Eli Zaretskii To: Simon Marchi CC: gdb-patches@sourceware.org In-reply-to: <2697b965-e108-5e7c-75d3-9baa7493141c@simark.ca> (message from Simon Marchi on Sun, 21 Apr 2019 08:55:07 -0400) Subject: Re: Fix lookup of separate debug file on MS-Windows References: <83ef5ze84y.fsf@gnu.org> <03da9895-5136-1da6-8c37-c4be0d06b608@gmail.com> <8336mfdumf.fsf@gnu.org> <831s1va7h8.fsf@gnu.org> <2697b965-e108-5e7c-75d3-9baa7493141c@simark.ca> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00412.txt.bz2 > From: Simon Marchi > Date: Sun, 21 Apr 2019 08:55:07 -0400 > > On 2019-04-21 8:05 a.m., Eli Zaretskii wrote: > > Ping! > > > > Would people please voice their opinions regarding preservation of the > > drive letter (and removing the colon) vs just dropping the drive > > letter altogether? I'd like to fix this issue for the upcoming > > release of GDB 8.3. > > I first read your patch (which initiated this thread), and my first reaction was > also to be surprised that we would lose the drive letter. The risk of clash > is low, but why take that risk at all when it's easy enough to keep the drive letter > and just strip the colon? OK, so how about the patch below? > I don't know the complete history of this, so if you know about distributions that > place debug files in a path without the drive letter (what your patch implements), > then I would be fine if GDB looked in both places, starting with the path including > the drive letter. I'm not aware of any Windows distributions that put debug info in the directory suggested by my previous patch. So I think we can safely use just the /X/ subdirectory method. diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index a3a5f3e..533a52c 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -19917,7 +19917,11 @@ 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. +directories of the executable's absolute file name. (On MS-Windows, +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 diff --git a/gdb/symfile.c b/gdb/symfile.c index 5736666..5749c61 100644 --- a/gdb/symfile.c +++ b/gdb/symfile.c @@ -1443,11 +1443,24 @@ find_separate_debug_file (const char *dir, = dirnames_to_char_ptr_vec (debug_file_directory); gdb::unique_xmalloc_ptr 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. */ + std::string drive; + if (HAS_DRIVE_SPEC (dir_notarget)) + { + drive = std::string (1, dir_notarget[0]); + dir_notarget = STRIP_DRIVE_SPEC (dir_notarget); + } + else + drive = ""; + for (const gdb::unique_xmalloc_ptr &debugdir : debugdir_vec) { debugfile = target_prefix ? "target:" : ""; debugfile += debugdir.get (); debugfile += "/"; + debugfile += drive; debugfile += dir_notarget; debugfile += debuglink;