Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: simark@simark.ca
Cc: gdb-patches@sourceware.org
Subject: Re: Fix lookup of separate debug file on MS-Windows
Date: Sat, 27 Apr 2019 10:56:00 -0000	[thread overview]
Message-ID: <83v9yzvhrl.fsf@gnu.org> (raw)
In-Reply-To: <835zr68kiw.fsf@gnu.org> (message from Eli Zaretskii on Mon, 22	Apr 2019 12:19:19 +0300)

Ping!  OK to commit the below to both branches?

> Date: Mon, 22 Apr 2019 12:19:19 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> CC: gdb-patches@sourceware.org
> 
> > From: Simon Marchi <simark@simark.ca>
> > 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<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.  */
> +  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<char> &debugdir : debugdir_vec)
>      {
>        debugfile = target_prefix ? "target:" : "";
>        debugfile += debugdir.get ();
>        debugfile += "/";
> +      debugfile += drive;
>        debugfile += dir_notarget;
>        debugfile += debuglink;
>  
> 


  reply	other threads:[~2019-04-27 10:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-18 13:49 Eli Zaretskii
2019-04-18 16:19 ` LRN
2019-04-18 18:41   ` Eli Zaretskii
2019-04-18 21:42     ` LRN
2019-04-19  6:48       ` Eli Zaretskii
2019-04-19 10:06         ` LRN
2019-04-21 12:06     ` Eli Zaretskii
2019-04-21 12:55       ` Simon Marchi
2019-04-22  9:19         ` Eli Zaretskii
2019-04-27 10:56           ` Eli Zaretskii [this message]
2019-04-27 16:16           ` Simon Marchi
2019-04-27 16:39             ` Eli Zaretskii
2019-04-27 18:56               ` Simon Marchi
2019-04-27 19:05                 ` Eli Zaretskii
2019-05-03  7:36                   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83v9yzvhrl.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox