From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48661 invoked by alias); 18 Apr 2019 18:41:30 -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 48653 invoked by uid 89); 18 Apr 2019 18:41:30 -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=arrangement, Drive, letter, drive 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; Thu, 18 Apr 2019 18:41:28 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37712) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHByM-0005yb-Sz; Thu, 18 Apr 2019 14:41:24 -0400 Received: from [176.228.60.248] (port=2529 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hHByK-00014V-Pk; Thu, 18 Apr 2019 14:41:22 -0400 Date: Thu, 18 Apr 2019 18:41:00 -0000 Message-Id: <8336mfdumf.fsf@gnu.org> From: Eli Zaretskii To: LRN CC: gdb-patches@sourceware.org In-reply-to: <03da9895-5136-1da6-8c37-c4be0d06b608@gmail.com> (message from LRN on Thu, 18 Apr 2019 19:19:39 +0300) Subject: Re: Fix lookup of separate debug file on MS-Windows References: <83ef5ze84y.fsf@gnu.org> <03da9895-5136-1da6-8c37-c4be0d06b608@gmail.com> 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/msg00357.txt.bz2 > From: LRN > 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.