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

[LRN <lrn1986 at gmail dot com>]

On 19.04.2019 9:48, Eli Zaretskii wrote:
>> From: LRN
>> Date: Fri, 19 Apr 2019 00:41:53 +0300
>>
>> 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.

If you built your gdb to look for debug files in a completely unpredictable
global directory (i.e. hardcoded 'f:/debugfiles' instead of letting gdb
autodetect the debug directory relative to its own runtime prefix), then your
only choice is to tell gdb at runtime that it should look for debug files in
'f:/debugfiles' (there's probably a command or an envvar that achieves this).
And you will have to place debug files in there by hand (or using some kind of
custom tool), because no one else knows in advance that debug files should go
into 'f:/debugfiles'.
This covers there "where the debug directory root is" part of the lookup. The
second part (path to the binary -> path to the debug file mapping) doesn't
depend on how you configure gdb.

> 
> 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.

If you didn't hardcode "f:/debugfiles", but hardcoded something along the lines
of "/debug/files" (instead of the default "/lib/debug"), then that is indeed
the case. Either way, the conventional "/lib/debug" path is no longer correct,
and the assumption made when debug files were built (the assumption that debug
files should be installed into "/lib/debug") and installed is false. So you are
right - in this case no one but you can know where the debug files should go. I
don't see how your desire to use unconventional debug directories is a valid
justification for gdb to not look in conventional debug directories.

If gdb and debugee are installed completely separately (in different root
directories), then you're right - prefix-aware lookup might not find the debug
files. Well, it *might* find them, if both packages follow FHS (i.e.
"c:/foo/bin/gdb" will look in "c:/foo/debugfiles/bin/bar" for a debug file for
"d:/zool/bin/bar", having concluded (how? i'm starting to doubt that this
scenario is going to work after all) that the adjusted path to 'bar' is
'/bin/bar'), but you certainly won't be able to have different debug files for
two different installs of a debugee in two different root directories.

Though i wonder who would want to do that - install gdb in a:/foo, install
debugee_v1 in b:/bar and install debugee_v2 in c:/zool...i mean, Windows
doesn't make it easy to install multiple things into multiple places, as you
have to add each 'bin' subdir to PATH, otherwise DLLs won't be found. This is
not scalable, and i wouldn't want to encourage anyone to do this.

> 
> 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.)

This is why i didn't raise the issue originally - i actually do place dbg files
in the same directory as their binaries. It's not clean, indeed, but it worked,
works, and will likely always work. So gdb's inability to correctly find debug
files in a separate debug directory is not critical to me.

>>>> 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.
>> 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.

It also makes sense if everyone follows the convention. It's like FHS - no one
forces you to follow it, but everyone benefits if you do, because everything is
where you'd expect it to be.

>  But that is a dangerous
> assumption, IMO.

Dangerous how?

>  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.

See below.

> 
>> 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.
> 

And yet that feature is a way to *both* follow an established convention for
Windows-installed Unix-originated programs *and* be able to install debugees in
multiple separate places with separate debug files that are correctly found by
a single instance gdb (which is also installed separately).

If your debugdir is 'c:/path/to/debugdir' and you're debugging
'f:/some/dir/usr/bin/foo' with gdb located in 'd:/programs/mingw/bin/gdb',
start by looking for

c:/path/to/debugdir/f/some/dir/usr/bin/foo

(no ambiguity), then try

c:/path/to/debugdir/some/dir/usr/bin/foo

(ambiguous drive), and then...that's it. If gdb and debugee are in different
root directories, prefix-aware lookup won't work (gdb doesn't know which part
of 'f:/some/dir/usr/bin/' to strip away). If you had gdb in
'x:/zool/usr/bin/gdb' and debugee in 'x:/zool/mingw/bin/foo', you'd also be
able to look for

c:/path/to/debugdir/mingw/bin/foo

This is both a feature and a bug.
A bug - because programs installed in different root directories have no way to
locate each other (as long as they don't all get put into PATH, in which case
you'll spend hours chasing after some delicious heisenbugs).
A feature - because you can have multiple root directories with multiple
independent installs, and they won't interfere with each other in any way (i
have, like, 4 of them at the moment, and the number will increase to 5 soon).

You can't just blindly do what Unix does and expect a good result - this isn't
Unix. There's an extra layer of complexity - arbitrary root directories.

Attachment: signature.asc
Description: OpenPGP digital signature