Re: Fix lookup of separate debug file on MS-Windows

[Eli Zaretskii <eliz@gnu.org>]

> From: LRN <lrn1986@gmail.com>
> Date: Fri, 19 Apr 2019 00:41:53 +0300
> 
> >> 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.
> 
> Wait, what?
> I've just built a "foo" program, it installs into `/mingw/bin/foo`, and i know
> that `/mingw/bin/gdb` will look for debug files in `/mingw/lib/debug` (note
> that gdb already does this, AFAIR). So it makes sense for me to install debug
> file for 'foo' as `/mingw/lib/debug/mingw/bin/foo`. I don't see why debug files
> can't be packaged like that.

You assume that you know how the end-user's GDB was configured.  But
that assumption is false in general.  E.g., I build my own GDB, and I
configure it with a global debug directory that you cannot possibly
know about in advance.

Moreover, the global debug directory is "relocatable", i.e. it is
computed based on the directory where gdb.exe lives, which makes its
exact place even less predictable in advance when an unrelated package
is being prepared.

By contrast, the .debug subdirectory of the binary's installation
directory is searched by default by every GDB build, so it is safer.
(You could also put the debug info file in the same directory as the
binary, but that is less clean, IMO.)

> I was also going to point out that distros do this, but Debian doesn't at the
> moment - it uses build-ids instead. But --build-id is relatively new, appeared
> in 2011. I distinctly remember that distros used debug directories before then
> (unless my memory is starting to give, that is)

The --build-id way is less convenient because AFAIK it requires to
tweak the link command.  It also requires creation of directories with
ugly long human-unreadable names.

> >> 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.
> > 
> 
> Looking for debug info for `/usr/bin/foo` in `/usr/lib/debug/usr/bin/foo` is
> OK, and the paths i described above are exactly the same, not deviating - just
> accounting for Windows specifics.

They omit the common prefix /some/directory/, unlike on Unix, where
/usr of /usr/bin is not omitted.  That's the deviation I alluded to.
And it runs afoul of the use case that you raised as an objection to
dropping the drive letter: programs by the same name installed in
different places.  If having such programs on different drives is not
rare enough, having them in different directories on the same drive is
even less rare.

> The specifics in this case being the fact
> that on Windows there's no pre-defined root directory, so packages that want to
> have a notion of a root directory have to pick *some* directory and consider it
> "root". Usually it's autodetected at runtime as the parent of the bin
> subdirectory where the binary is (conveniently, all binaries go into bin
> subdir; and yes, this is problematic for plugins - but they usually don't need
> to know where the root is). Once you consider the "c:/some/directory" part of
> the paths above as "some path to root directory that we don't take into
> account", everything becomes clear. (i'm explaining this just for the sake of
> the argument, since you already know all this).

What you say will make sense only if people install software from a
single source, like the MSYS2 project.  But that is a dangerous
assumption, IMO.  It is better to have a system that doesn't make such
an assumption, especially since what I propose is more closely
following what happens on Unix.

> As i've said, all these approaches are not mutually-exclusive, gdb can be made
> to look in *all* of these places until it finds a debug file.

That would need to be a general feature, not limited to Windows.