From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100003 invoked by alias); 18 Apr 2019 16:19:50 -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 99995 invoked by uid 89); 18 Apr 2019 16:19:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=Drive, H*RU:sk:broadba, HX-Spam-Relays-External:sk:broadba, H*r:sk:broadba X-HELO: mail-lf1-f53.google.com Received: from mail-lf1-f53.google.com (HELO mail-lf1-f53.google.com) (209.85.167.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 18 Apr 2019 16:19:48 +0000 Received: by mail-lf1-f53.google.com with SMTP id j11so2088525lfm.0 for ; Thu, 18 Apr 2019 09:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:references:from:autocrypt:subject:message-id:date:user-agent :mime-version:in-reply-to; bh=93fQD+O1vSyv6s+PQLUXWtPl77V/aImS9Y2clNipZkQ=; b=Fzo5ytGeZW39y6tzSu5U6hNbDGq6PEuvUS1DrC6SAJfjdmw0d7lBxYLDUumhhydYvf D9tinO09HLYtp4IsM3MPI5E0wRTCsPZiyMiGeFxNrrPm5i/dl32Lk1JIGjqwN4++RcbH buXuhdj3RqykMEKP31ddFB0WdQ5PRDhE1dNGGJXXZ/hgzXKfv9xZJ+9ECYDQPe0m1M83 QnFb55tNo9jyAaqEg70fmCOgaGJAyUHh2jWoXn0fjkUWG43LCWSssXiOokoz8su8dAOj dqlCGBGxrnRUHjhOlR61R2gUvfevv84CUfalxOeP/xmV6IDMxCAvaPzzJOkZZdHijobb q6rA== Return-Path: Received: from [192.168.4.39] (broadband-95-84-200-6.ip.moscow.rt.ru. [95.84.200.6]) by smtp.gmail.com with ESMTPSA id l5sm539542lfh.70.2019.04.18.09.19.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Apr 2019 09:19:44 -0700 (PDT) To: gdb-patches@sourceware.org References: <83ef5ze84y.fsf@gnu.org> From: LRN Subject: Re: Fix lookup of separate debug file on MS-Windows Message-ID: <03da9895-5136-1da6-8c37-c4be0d06b608@gmail.com> Date: Thu, 18 Apr 2019 16:19:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <83ef5ze84y.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WDQoos1kzF5KE83mwuRqUkxmYzBmPlsVB" X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00345.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WDQoos1kzF5KE83mwuRqUkxmYzBmPlsVB Content-Type: multipart/mixed; boundary="WDBz3Pqoko1Zur7hv5knAwsvbR5vEjtLX"; protected-headers="v1" From: LRN To: gdb-patches@sourceware.org Message-ID: <03da9895-5136-1da6-8c37-c4be0d06b608@gmail.com> Subject: Re: Fix lookup of separate debug file on MS-Windows --WDBz3Pqoko1Zur7hv5knAwsvbR5vEjtLX Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Content-length: 3973 On 18.04.2019 16:49, Eli Zaretskii wrote: > If you put the separate debug file in a global debug directory, GDB on > MS-Windows will currently fail to find it. This happens because we > obtain the directory to look up the debug file by concatenating the > debug directory name with the leading directories of the executable, > and the latter includes the drive letter on MS-Windows. So we get an > invalid file name like >=20 > d:/usr/lib/debug/d:/usr/bin/foo.debug >=20 > + /* MS-Windows/MS-DOS don't allow colons in file names; we must strip > + the drive letter, so that the file name resulting from splicing > + below will be valid. */ > + if (HAS_DRIVE_SPEC (dir_notarget)) > + { > + dir_notarget =3D STRIP_DRIVE_SPEC (dir_notarget); > + /* We will append a slash to debugdir, so remove the leading > + slash as well. */ > + if (IS_DIR_SEPARATOR (dir_notarget[0])) > + dir_notarget++; > + } > + 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? What if the path to "foo"= is: c:/some/directory/bin/foo ? In that case your patch will produce: d:/usr/lib/debug/some/directory/bin/foo Actually, no, that's not right. If gdb and 'foo' are in the same tree (this= is a valid case, for example, if you're dealing with a mingw installation), th= en gdb will autodetect debug directory as 'c:/some/directory/lib/debug', and t= he debug path will be: c:/some/directory/lib/debug/some/directory/bin/foo To make it more obvious: c:/some/directory/mingw/bin/foo + c:/some/directory/mingw/bin/gdb (meaning c:/some/directory/mingw/lib/debug debug directory) will produce c:/some/directory/mingw/lib/debug/some/directory/mingw/bin/foo , if i'm not mistaken. So the problems i see with this approach are: 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/'. 2) This doesn't take runtime tree location into account. Your debug tree ha= s 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 beg= in 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 us= er just used that as a root of an installation. The package maintainer can't k= now where the binaries will end up, and can only predict the '/mingw/bin/foo' p= art. 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 (depending on whether we consider '/mingw' or '/' as the root directory; probably the former, although some people might make a case for the latter), and this is where a package manager can put the files (the package will con= tain '/mingw/lib/debug/bin/foo' debug file, and the package manager will prepend= the install root to that path when installing). Note that (1) and (2) somewhat contradict one another. One way to satisfy everyone is to implement all lookups (with the prefix fi= rst, then with the absolute path with a drive letter; after that it might even t= ry the without-drive-letter case, or something else, as long as the debug info file isn't found). This is not unheard of - for example, gcc can look for include files in multiple non-existing directories, to support different installation schemes. (the reason why i have such a detailed opinion on the matter is that i've debugged this very code for my latest gdb patch[0], which i submitted last month, and back then i noticed the same behaviour you did). [0]: https://www.sourceware.org/ml/gdb-patches/2019-03/msg00082.html --WDBz3Pqoko1Zur7hv5knAwsvbR5vEjtLX-- --WDQoos1kzF5KE83mwuRqUkxmYzBmPlsVB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE4MWzR43wYaAzEA49ja3pJ2dZunQFAly4o5sACgkQja3pJ2dZ unSJkA//VW2+oI6R+SyYv7W/lXjoxHsNCArtJUzgN2p0T4QCBfg9aukfsZMzKdD6 u3MVygHkLmPosyW/MDkm/oSjFHdTjHDUIXJ9KNMehC5HBDjynIC228EwJiK4rv0V D/UqgG/WR55ZIiUwk2HyKPPsGmDsZj61HLp+z0fFNBrQPcqFgLFbWv8BOJyVE2Qe OLC6lSHnWl6q6dxARc9txvSFOnxRcCxMqziEkClgoh78ZkcJoHI+sUmWwp+Kp61z SjGnAxz8DIICeXWa5YnGB3Gs15TL8mqHQ37ED1bRjTA7cHwsTg5BGiZUJtMmz51Y urtUZ2KLVxzBkGG8dF4rHSA/x6Ta7vpDv4MuL2kR0MwO2B4xCFWJEPQc+hTUAftg pFRUXlnn1ADUXEWoBC7iEKwMGne8PFTnT/sg6S5AvYarHhTzKJCZgpVGnDy9BKyL 5QzE1dGABuZtJfsg9gAJDeMjdKUqp9xx3TfCkp6KJ2CUavy85i3GzMCBOs0RYQbN KIORBql/mtGHaF0ykA4bzpfHKqHX1JtYz5kPxkOBNQD9ezISGxngWZcd5rwL3YKT sY/yZeJI46oEulRCqdV8o+8cQ82QDhHFqFZ2pveThPBNfPfvTNcQmT5RSda81Ygn kWUXsPYqa5VIqiWx5IyR/hnS9RWKvJ0EBGXJF38S48pV1Ynnnpc= =uSHE -----END PGP SIGNATURE----- --WDQoos1kzF5KE83mwuRqUkxmYzBmPlsVB--