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

[LRN <lrn1986 at gmail dot com>]

On 18.04.2019 21:40, Eli Zaretskii wrote:
>> From: LRN 
>> Date: Thu, 18 Apr 2019 19:19:39 +0300
>>
>> 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.

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.

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)

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

Unless you meant strictly the second string (the one with a stripped '/mingw'
prefix), in which case i would agree that this is more-or-less unortodox, even
if somewhat plausible.

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.

Attachment: signature.asc
Description: OpenPGP digital signature