From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69003 invoked by alias); 19 Apr 2019 06:48:33 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 68994 invoked by uid 89); 19 Apr 2019 06:48:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=alluded, accounting, packaged, afair X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 Apr 2019 06:48:31 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45596) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHNK1-0003Gj-3X; Fri, 19 Apr 2019 02:48:29 -0400 Received: from [176.228.60.248] (port=3696 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hHNK0-0007tO-Cg; Fri, 19 Apr 2019 02:48:28 -0400 Date: Fri, 19 Apr 2019 06:48:00 -0000 Message-Id: <83o952cwyd.fsf@gnu.org> From: Eli Zaretskii To: LRN CC: gdb-patches@sourceware.org In-reply-to: (message from LRN on Fri, 19 Apr 2019 00:41:53 +0300) Subject: Re: Fix lookup of separate debug file on MS-Windows References: <83ef5ze84y.fsf@gnu.org> <03da9895-5136-1da6-8c37-c4be0d06b608@gmail.com> <8336mfdumf.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00367.txt.bz2 > From: LRN > 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.