From: Eli Zaretskii <eliz@gnu.org>
To: gdb-patches@sourceware.org
Subject: Re: Fix lookup of separate debug file on MS-Windows
Date: Sun, 21 Apr 2019 12:06:00 -0000 [thread overview]
Message-ID: <831s1va7h8.fsf@gnu.org> (raw)
In-Reply-To: <8336mfdumf.fsf@gnu.org> (message from Eli Zaretskii on Thu, 18 Apr 2019 21:40:56 +0300)
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.
> Date: Thu, 18 Apr 2019 21:40:56 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> CC: gdb-patches@sourceware.org
>
> > From: LRN <lrn1986@gmail.com>
> > Date: Thu, 18 Apr 2019 19:19:39 +0300
> >
> > While this is *a* fix, the result, AFAIU is:
> >
> > d:/usr/lib/debug/usr/bin/foo.debug
> >
> > This is a functional filename, but is it correct?
>
> It fits the documentation, so yes.
>
> > 1) Drive letters are lost (meaning that you can't have two paths with equal
> > names on two different drives be mapped to different debug tree paths - they
> > only differ in the drive letter, and you make that letter disappear)
> >
> > A more correct way to fix this is to replace 'X:/' with 'X/'.
>
> We could do that, but it will need a documentation change. I think
> it's overkill, as the chances of the binaries and the debug directory
> to be on different drives are nil, but if others prefer to convert X:/
> to X/, I'm fine with that.
>
> > 2) This doesn't take runtime tree location into account. Your debug tree has to
> > reflect the absolute, Windows path to the binary (since you're not doing any
> > other adjustments, and since gdb gives you an asbolute, Windows path to begin
> > with), otherwise gdb won't find the debug files.
> > I.e. in the 'c:/some/directory/mingw/lib/debug/some/directory/mingw/bin/foo'
> > example above the second '/some/directory' is clearly incidental, as the user
> > just used that as a root of an installation.
>
> It is as "incidental" as the same situation of Posix platforms, where
> we simply splice the two directories.
>
> > The package maintainer can't know where the binaries will end up,
> > and can only predict the '/mingw/bin/foo' part.
>
> Package maintainers shouldn't use global debug directories, because
> for starters such directories might not exist at all, and even if they
> do, their location cannot be predicted in advance. Package
> maintainers should instead use the .debug subdirectory of where they
> put the binaries, that arrangement already works, and is predictable.
>
> > I.e. the path that gdb should look for should be:
> >
> > c:/some/directory/mingw/lib/debug/mingw/bin/foo
> >
> > or
> >
> > c:/some/directory/mingw/lib/debug/bin/foo
>
> This would deviate from what we do on Unix, so I'm opposed to it.
> Unless we also change the Unix behavior, of course.
>
next prev parent reply other threads:[~2019-04-21 12:06 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 [this message]
2019-04-21 12:55 ` Simon Marchi
2019-04-22 9:19 ` Eli Zaretskii
2019-04-27 10:56 ` Eli Zaretskii
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=831s1va7h8.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).