From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24605 invoked by alias); 19 Apr 2019 10:06:37 -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 24597 invoked by uid 89); 19 Apr 2019 10:06:37 -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, desire X-HELO: mail-lf1-f46.google.com Received: from mail-lf1-f46.google.com (HELO mail-lf1-f46.google.com) (209.85.167.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 Apr 2019 10:06:35 +0000 Received: by mail-lf1-f46.google.com with SMTP id t11so3704747lfl.12 for ; Fri, 19 Apr 2019 03:06:35 -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=kOlGKmU9VowJHwj3s+imfmCXEYiEQz3WnUqFL6X3H7E=; b=QmJPBEmUtQNUey8tUsagvS+fXXZ+pHMmm2pu7Nk8LgwFja/xXEIM6mcfX9TfuAi9g/ cIj3/ZcykAsOUDiponoMFkM3aQCf0AheX/ko9aDiayjyyi28lyAit/OsPDUvIDDHMkB0 hBrwJ2Y/cK+po6xiB00ifCbknvYuDPQkX2OjGL/P2fQWSkT2/4ycHYi5DiwAN6/M3C1M 7x6VT2m0Z4/iN6ZcKbiBUYs7/9tF10QfKAAQc7TkouAJQU6Z0mXqReF+vOx2ga9Ziz31 AiCQSFnRwxxlb/ZpjYGVohHEBUmNybip9c0zS6ChiNL79Q9o+0iO+dC2ddO1q2f0qRL3 fB1Q== 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 1sm924824ljw.56.2019.04.19.03.06.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Apr 2019 03:06:31 -0700 (PDT) To: gdb-patches@sourceware.org References: <83ef5ze84y.fsf@gnu.org> <03da9895-5136-1da6-8c37-c4be0d06b608@gmail.com> <8336mfdumf.fsf@gnu.org> <83o952cwyd.fsf@gnu.org> From: LRN Subject: Re: Fix lookup of separate debug file on MS-Windows Message-ID: <5d63466f-5f3f-8912-cb67-e394ef05c978@gmail.com> Date: Fri, 19 Apr 2019 10:06: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: <83o952cwyd.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EHci5bBSmCfpkxS91falxOwqXE7AePLKc" X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00369.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EHci5bBSmCfpkxS91falxOwqXE7AePLKc Content-Type: multipart/mixed; boundary="xDOVrKLtnAqPzDQ6ZagFYfl8wLiDkWeLL"; protected-headers="v1" From: LRN To: gdb-patches@sourceware.org Message-ID: <5d63466f-5f3f-8912-cb67-e394ef05c978@gmail.com> Subject: Re: Fix lookup of separate debug file on MS-Windows --xDOVrKLtnAqPzDQ6ZagFYfl8wLiDkWeLL Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Content-length: 7465 On 19.04.2019 9:48, Eli Zaretskii wrote: >> From: LRN >> Date: Fri, 19 Apr 2019 00:41:53 +0300 >> >> 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` (n= ote >> 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 debu= g files >> can't be packaged like that. >=20 > 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. If you built your gdb to look for debug files in a completely unpredictable global directory (i.e. hardcoded 'f:/debugfiles' instead of letting gdb autodetect the debug directory relative to its own runtime prefix), then yo= ur only choice is to tell gdb at runtime that it should look for debug files in 'f:/debugfiles' (there's probably a command or an envvar that achieves this= ). And you will have to place debug files in there by hand (or using some kind= of custom tool), because no one else knows in advance that debug files should = go into 'f:/debugfiles'. This covers there "where the debug directory root is" part of the lookup. T= he second part (path to the binary -> path to the debug file mapping) doesn't depend on how you configure gdb. >=20 > 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. If you didn't hardcode "f:/debugfiles", but hardcoded something along the l= ines of "/debug/files" (instead of the default "/lib/debug"), then that is indeed the case. Either way, the conventional "/lib/debug" path is no longer corre= ct, and the assumption made when debug files were built (the assumption that de= bug files should be installed into "/lib/debug") and installed is false. So you= are right - in this case no one but you can know where the debug files should g= o. I don't see how your desire to use unconventional debug directories is a valid justification for gdb to not look in conventional debug directories. If gdb and debugee are installed completely separately (in different root directories), then you're right - prefix-aware lookup might not find the de= bug files. Well, it *might* find them, if both packages follow FHS (i.e. "c:/foo/bin/gdb" will look in "c:/foo/debugfiles/bin/bar" for a debug file = for "d:/zool/bin/bar", having concluded (how? i'm starting to doubt that this scenario is going to work after all) that the adjusted path to 'bar' is '/bin/bar'), but you certainly won't be able to have different debug files = for two different installs of a debugee in two different root directories. Though i wonder who would want to do that - install gdb in a:/foo, install debugee_v1 in b:/bar and install debugee_v2 in c:/zool...i mean, Windows doesn't make it easy to install multiple things into multiple places, as you have to add each 'bin' subdir to PATH, otherwise DLLs won't be found. This = is not scalable, and i wouldn't want to encourage anyone to do this. >=20 > 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.) This is why i didn't raise the issue originally - i actually do place dbg f= iles in the same directory as their binaries. It's not clean, indeed, but it wor= ked, works, and will likely always work. So gdb's inability to correctly find de= bug files in a separate debug directory is not critical to me. >>>> 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 cons= ider 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" pa= rt 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 sa= ke of >> the argument, since you already know all this). >=20 > What you say will make sense only if people install software from a > single source, like the MSYS2 project. It also makes sense if everyone follows the convention. It's like FHS - no = one forces you to follow it, but everyone benefits if you do, because everythin= g is where you'd expect it to be. > But that is a dangerous > assumption, IMO. Dangerous how? > 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. See below. >=20 >> As i've said, all these approaches are not mutually-exclusive, gdb can b= e made >> to look in *all* of these places until it finds a debug file. >=20 > That would need to be a general feature, not limited to Windows. >=20 And yet that feature is a way to *both* follow an established convention for Windows-installed Unix-originated programs *and* be able to install debugee= s in multiple separate places with separate debug files that are correctly found= by a single instance gdb (which is also installed separately). If your debugdir is 'c:/path/to/debugdir' and you're debugging 'f:/some/dir/usr/bin/foo' with gdb located in 'd:/programs/mingw/bin/gdb', start by looking for c:/path/to/debugdir/f/some/dir/usr/bin/foo (no ambiguity), then try c:/path/to/debugdir/some/dir/usr/bin/foo (ambiguous drive), and then...that's it. If gdb and debugee are in different root directories, prefix-aware lookup won't work (gdb doesn't know which pa= rt of 'f:/some/dir/usr/bin/' to strip away). If you had gdb in 'x:/zool/usr/bin/gdb' and debugee in 'x:/zool/mingw/bin/foo', you'd also be able to look for c:/path/to/debugdir/mingw/bin/foo This is both a feature and a bug. A bug - because programs installed in different root directories have no wa= y to locate each other (as long as they don't all get put into PATH, in which ca= se you'll spend hours chasing after some delicious heisenbugs). A feature - because you can have multiple root directories with multiple independent installs, and they won't interfere with each other in any way (i have, like, 4 of them at the moment, and the number will increase to 5 soon= ). You can't just blindly do what Unix does and expect a good result - this is= n't Unix. There's an extra layer of complexity - arbitrary root directories. --xDOVrKLtnAqPzDQ6ZagFYfl8wLiDkWeLL-- --EHci5bBSmCfpkxS91falxOwqXE7AePLKc 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----- iQIzBAEBCAAdFiEE4MWzR43wYaAzEA49ja3pJ2dZunQFAly5naAACgkQja3pJ2dZ unQgzw/+NeQAlUJEO5LQIMNnfHcOGiKp9gdfxRyx/bd1sLOq357iKdcIcOEtYpA7 A1j05UnokYvc50i83l3yc/0yFu+xkU6+jip/gCo4RuavX18jWuA3oGIOnE2hiQ9R PTR9oupRrJrBSRpLgssSxxcWii0i1EZHNEbbmJzu68hKvGdlK7aBA6ZnaHxXgRTX jl3hd/MSXP0hnD0t6eZaEjYYEJNTLGXZHYPcdKg+UIlmuNaxMtlJFGPPkDRrMrfG V7kRngFacXNsXJ3R8MT0X35J6AnvU0nHHcSx/pMqCqzUBl5+hnKxmVrNkfQTuF1m uFkxkkjFp2++W7Vj6aV5+ISMvLnleV021ySeYMsDj6GRXyRDMZhHJE+JMF6Q1j2/ 4XSDoAjWluO2AHaeAoXXDtLTtkA5AbDvv8b/GslH7o2etK8sURoSTRxRb5kzbZ7N hzOPdVjrid/NlNkzF5DKhwxPoRUgiTrm+75Ygzm4O/Xez6lOXneHAi1pzTiiilEP ciK7XYl3glby/0zL9GtUJdv0LxrvFX4+JkxxfEYfIEJzgr2bhyHDeegMEwzuDFx7 nWUIepZI18KCxNpRZ8nifCXyQ8Hwc377nvTfe1wBdDLwPkb/s4RkRFHrQrHer+TZ AD2RjS4cw8OzQSpWQVqwXogW/877EcRKoYuxRfDPDeUfqgI3+kA= =38zt -----END PGP SIGNATURE----- --EHci5bBSmCfpkxS91falxOwqXE7AePLKc--