From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78416 invoked by alias); 18 Apr 2019 21:42:05 -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 78271 invoked by uid 89); 18 Apr 2019 21:42:05 -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=H*RU:sk:broadba, HX-Spam-Relays-External:sk:broadba, H*r:sk:broadba, accounting X-HELO: mail-lf1-f51.google.com Received: from mail-lf1-f51.google.com (HELO mail-lf1-f51.google.com) (209.85.167.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 18 Apr 2019 21:42:04 +0000 Received: by mail-lf1-f51.google.com with SMTP id k18so2666426lfj.13 for ; Thu, 18 Apr 2019 14:42:03 -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=fa+12wX52Ssw2OiEuNhyQSIZYxFbNwv+yhkvpVkCZZ0=; b=EWjf8akYyQD9U2QIbfRB/ySZI0A9kqqvGNcRE4DjvvFouCHUVVpFHSVoo6v/0WK9kb nO8mwUv57ocAIjcdIuVh5yRyEj23HEMN8FQ/ZTgT31A310/yyz4Yfw5hWtavcWsPHb7k FY4B6aovvWtVYESGlPOnF9gRV3AGnpIt6B9DKVQLfkclnE62mbEv5IgWIqqDRwZDB4KC qh/SyG7vuotinIYkQE8ETT1ESnwNboowXs4q7s66wM7YoU2Jop4HHqE1tZYwEo8+d3vh acdvS2zWQUIV7qAUF/50cmdMDUzEk8xhbbpMKlvPWO7CYauPMpUUsklOfsMRMSOqTq3g bcDw== 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 f18sm675665lfh.39.2019.04.18.14.41.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Apr 2019 14:41:59 -0700 (PDT) To: gdb-patches@sourceware.org References: <83ef5ze84y.fsf@gnu.org> <03da9895-5136-1da6-8c37-c4be0d06b608@gmail.com> <8336mfdumf.fsf@gnu.org> From: LRN Subject: Re: Fix lookup of separate debug file on MS-Windows Message-ID: Date: Thu, 18 Apr 2019 21:42: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: <8336mfdumf.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="se4dge4LoGdf8oGqQWduezlS2gukj7iwD" X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00361.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --se4dge4LoGdf8oGqQWduezlS2gukj7iwD Content-Type: multipart/mixed; boundary="WQHzeCsDGULfjAzsrl36BzrQYwG94U8ZL"; protected-headers="v1" From: LRN To: gdb-patches@sourceware.org Message-ID: Subject: Re: Fix lookup of separate debug file on MS-Windows --WQHzeCsDGULfjAzsrl36BzrQYwG94U8ZL Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Content-length: 3399 On 18.04.2019 21:40, Eli Zaretskii wrote: >> From: LRN=20 >> 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. >=20 > It is as "incidental" as the same situation of Posix platforms, where > we simply splice the two directories. >=20 >> The package maintainer can't know where the binaries will end up, >> and can only predict the '/mingw/bin/foo' part. >=20 > 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 k= now 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 deb= ug file for 'foo' as `/mingw/lib/debug/mingw/bin/foo`. I don't see why debug f= iles can't be packaged like that. I was also going to point out that distros do this, but Debian doesn't at t= he moment - it uses build-ids instead. But --build-id is relatively new, appea= red in 2011. I distinctly remember that distros used debug directories before t= hen (unless my memory is starting to give, that is) >=20 >> 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 >=20 > This would deviate from what we do on Unix, so I'm opposed to it. > Unless we also change the Unix behavior, of course. >=20 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 - j= ust 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 wan= t to have a notion of a root directory have to pick *some* directory and conside= r 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 n= eed 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 '/ming= w' prefix), in which case i would agree that this is more-or-less unortodox, e= ven if somewhat plausible. As i've said, all these approaches are not mutually-exclusive, gdb can be m= ade to look in *all* of these places until it finds a debug file. --WQHzeCsDGULfjAzsrl36BzrQYwG94U8ZL-- --se4dge4LoGdf8oGqQWduezlS2gukj7iwD 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----- iQIzBAEBCAAdFiEE4MWzR43wYaAzEA49ja3pJ2dZunQFAly47yEACgkQja3pJ2dZ unRRJxAAht/EC0570SPNC3km1Ul35H25pVamjUDUgNHgxA3y4gCa8KNBQ6ZIHo8x Sq5uYpxSlbOLG09vBU1cx9BqCUmUC+CnkPiDLPXGFlbMjTw8gKn3RHnx2w2IGqmB kh3wPiBFFq45KGkZUntz+Not8314qY9oSPrML5EBfPCIodWd8jNur/XD88EeXujK m1dbLOaLfNLl6hyHZjnenAF9FFD7RaQ3YQsuysg7eKg0iyan0docDfqMt4bBRG29 erSRLE32Pj+etV6oGwBHl0no1dEGYohtd/v+LegsN7cWi4e5xL1csnnDkBEewYCx uPI8WSyHuCPB/h9feGlaKLXC/sbFoITJNYelb1ff1y72TwPtzyupIC5KNcAC4hPC D35P+gDQyszroX9gYMib6c6O5ufLbBc060Sxka2BwY9LPCVs9Gv2nTkOlpAG8KGz 0hm6qOas42x9kyJZtSZ+2NwqiE0LBfYhgX3Tt9yYUvbd2toziLKCXmATtQj2FcsF EKn8oRVh0edoi3WgU5igFuDu016hTsTdpoYQal6WNESazht6VlSO0NOeRS3x3s46 72gWlEMEzXXnqF7TixmBEZKD3gssCXYUWl9rzH6txbDL1Sh9tm46zR3zCDYNfAOn Yhqu9SYX4Se7fk8p6dZZlD8MHCDFI8SQYRbMxnWFuQ4iE9z+vHY= =Rl1E -----END PGP SIGNATURE----- --se4dge4LoGdf8oGqQWduezlS2gukj7iwD--