From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by sourceware.org (Postfix) with ESMTPS id D6A593877006 for ; Tue, 17 Mar 2020 17:46:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1584467210; bh=nqpqLcMfH+p//0vXGgRFqzxE6NIAILDILmPEFGKoWKk=; h=X-UI-Sender-Class:To:References:From:Subject:Date:In-Reply-To; b=DNdc+ne4KELlWfsweo8Iw7TK56BG+UqUeyxJnVX9gDi61edBN0k1QGz37gv3XdF/B pCJV39civ/eSJ9JWeMczRLpS0gBKn7OyVaNh421AlKTqFZP8FUxoVgkmwYtaMk5RT6 EKKuEpYLtZJ/C5WEEDT9x7HLP1rIkHwttIm/ouWQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.0.241] ([89.79.191.25]) by mail.gmx.com (mrgmx105 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MZCbB-1ijJCF2qmH-00VCgR; Tue, 17 Mar 2020 18:46:50 +0100 To: Simon Marchi , gdb-patches@sourceware.org References: <20200317163020.28790-1-n54@gmx.com> <597c7d5f-dfd5-53a8-3369-4042d4cd653a@simark.ca> From: Kamil Rytarowski Autocrypt: addr=n54@gmx.com; prefer-encrypt=mutual; keydata= mQINBFVwUF8BEADHmOg7PFLIcSDdMx5HNDYr8MY2ExGfUTrKwPndbt3peaa5lHsK+UGoPG48 KiWkhEaMmjaXHFa7XgVpJHhFmNoJXfPgjI/sOKTMCPQ5DEHEHTibC4mta7IBAk+rmnaOF0k8 bxHfP8Qbls66wvicrAfTRXn/1ReeNc3NP4Sq39PoVHkfQTlnQiD4eAqBdq61B7DhzjhbKAZ4 RsNtLfB6eOv9qvmblUzs50ChYewM9hvn+c7MdDH+x2UXoSDhkBDkKcJGkX91evos8s9AuoEd D32X5e+bmdUGe8Cr3cAZJ8IEXR6F9828/kxzPliMsCWVRx1Fr28baCJOUGgFPNr3ips78m9+ Iw8PdQ101jU0dvucDFxw/1SCGYEZzV+O/237oRPuLCiDX5nhQoxf6dn9ukQleLBMNy2BLI4H g342NhF21HLA+KlyLOHaMKQCKzlal+zVNZTRTCh/ikMhsxWQjBfnqTDbMj85DnWwtump27SI qhPjUnS0a6MKoS/A+hbi64k5zztkvloELfCSrX7NyBTT0jgF2IGFIxZMrKCtQ9StcGMCV9MX tjcBy6fj7QMontEaIDRJEMjg8UIGw1B687OhalOv1ISia4xOWvpYAM6ipgqh6tBQmFzasL9P h1RtcVdFpFbhwVlr1Bly8c25gBNQHL5GUjLMn45LlQz50OzrkwARAQABtCdLYW1pbCBSeXRh cm93c2tpIChOZXRCU0QpIDxuNTRAZ214LmNvbT6JAjwEEwEIACYCGyMHCwkIBwMCAQYVCAIJ CgsEFgIDAQIeAQIXgAUCVbKGFwIZAQAKCRBLswjpsC52bIVpD/9i8npieI91xMIVvAHIUMeo cQO0IrNb+b/PuTj2qNemdwU7dhVJ7tVU5O1H2hI2M4rHGzjzDTxYzdxka0+A8CVEuvFdf6sF lXlXF0wM7rC6MoaB0QLAKxkZB5OtCILxLx7Bl2Y4cTPMU9v+qSL6yrdmhxogkufa4d6O9Zl/ FCWO2kH/BphKOiDtbyvdo2WULSLWP2IXN+0rCpNL4wbTfYLgV9JtMf8f0naGsdy7BFuDWsIE vtHh8dkQZP7dz6Qy67kx8negZaehSEgXwiae0HwQIn3xTQrFmBDALDsCgXuLWPTvglSkqTak uG+8X5fyTy0cU10TNKsU+rFBO+/xsUoIQOGrARwfWOIfJNPelzh/qigSnyNQNH8u5vFRPg9n fqB/AcvvAvtOYOo8EN9Ofx11gNj397NXc5HBQTrX6k5GNAeBWE3Ng1uO6scIwAS7qGnqGezU ABmQKLN37gmJiiGwhQAnSE6HILLBC5Z2b0S2rQsPKg8WgUmPa1YIcDkDtNB/LJcDsdU4Fm+r U2ksKU7tGD2ZfBt8H2nqfPKKeB+Uv/TBigjRvx/m70vjhqVxwCZA9Fqr9vkQkZroNfqP+3dp Z5V5fjmxO5abE2+IikSvFagwMtgx56i8Yrr2BzE8P5/S4cKq1kgyQoF+lVGDKRkUKCv1i4Fo aftnSxN8jTFZDbkCDQRVcFBfARAAutbzb8wAHGL5FPPWKErQ3Bsrp9RDTVqRzp7kBMOtd/14 MrOsWWyiml4XnvBYsJuhZWomFoeulcOXAPoTJ2vTw6erWYtdOiZymfQ3GMWpxzgkOVeNjsFF 9AQ38FCMKmIDs9dgn+KXSIXlZA34khKLd163SN5U/KHfYlnnocec31u+7rVa1hlF5DBSSpoi s8cs41foBYC5NsB/i+yqGIlfzHy7pC2u5kyQCuJotLH4y0rT5X+YBC7z7cqKChtILNDGw0ht qps29fwOGBE/FWmu8CbpSHj8pvg7uUyQcKbZbNChBfWtOJKdjnNs5VHf2ec95SwYmWl6Xz66 G892HY4ODtvl05/kh0qtdJd2oI4gJBsBx/N1585/3JYN4k78GIHTnML3xJydRRs9wwM3AXf/ iDGrMyY7qHQVXJLdO5nPe7LHg48vryCMkBnTMw5iNFPVCu5w1BaZyHxuS2HvpsgUtQoBa2QE P1jYNI+2qgoiIG4VQDhYtrD0WJaYdi/C2UVDxRy07dt73SV3RQ7ijOiUrz4g3/deFKY16/1k sE+N5Sc5Tjt84ChjO3nJRbHrQxd6dCOElR70e3R2yAuSB4m7LJpO20IB9CtWhlF/0AtfL91W O8GGGqLWB0Z04hmwRs/l8T4WWIlykLshbunWN6jsP1Y27FeilTZ+Pc9mYOEUFfEAEQEAAYkC HwQYAQgACQUCVXBQXwIbDAAKCRBLswjpsC52bPayD/9jE8mdNudrudSxbDB2vf8pU8r5flCq vIkfOdpZGV/Wx/Zx+HFHHp+b2aNBGSNyFTnph1Ku9bvg06vD0o+b7SdA1vrBgRG41t0OCIyf vejz65Xpin2EtCllcBM8zUCxHo43blON8fNw70P1Ec0loBp4TAal1MiXbB8kxRTRcEPVO9YF 9NPsFxycoWl0ZSvu4ESrQlrjRbVv+W0Fy/XqcQwEtDziFQHQXNRbTy8INPD49CsB7BkKRK+f 1vMmw7SxfsyEhyCgo9ZWfHb/+w9T5h+UhF87L/m287z7W+s4aCAPBzjbIWhtngGJJwIgiWdI I9J6YJLcHLvVZLw7xzA/flcjc0VfzOgJOJw3hBukHnEz7/CKgnABwyNu52P+PQbxVTiTjMKm 06eV732u9ZLD9ZgEazfmyGDHzsuzoXwsRnmcnbwYYAiynS+vfGl5oMtMa5qzsPhlzuvRlXHm zr8VjF8c9RThvyZyyHtWYAqNmBecMvM0whigjMeoAMJ5LtpyZgxjbHj1XnVdNBZgfJkOzsc/ twffi7RYphRx0d9z5UZ1Yl5Rvl05vTaJ7YhhNC7xuE8yGOQmDUsPDwWqO/eXUDErJjCOBR5b 0yILqRPYNT0Fj/th9gtEbZy1Gp0TVBkZM3tfjDRu43Pn6iSKObO/j0rNuq1LwN/EMxDifeZO 4XSbcg== Subject: Re: [PATCH] Return unconditionally ptid.pid () in get_ptrace_pid() for NetBSD Message-ID: <72744690-5add-413e-a4cf-ada6cf8bd5e9@gmx.com> Date: Tue, 17 Mar 2020 18:45:41 +0100 User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <597c7d5f-dfd5-53a8-3369-4042d4cd653a@simark.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RVe1B4LtKIapFERFEmoxrJenyhil7SAQy" X-Provags-ID: V03:K1:IS0x5ekh6kL8eI6d6zBwfDlJZBWkjSw1Lg4B9ST1spe1ENNLfb7 RpvHDhMG+/m0dDqbzeRG7iyqTFvQjYMJH+L9ORbfupqfSN5myYhvZKlfNnioRNpWYLgdHMN hsyjUi8+H1w5E9oMYOg8Lu20YytW55xUqN93RRue1UDgsCMC/2uzz1jPrCj7yFb9aWFirm+ dA1he7DXw+uNjLYbrQ4fA== X-UI-Out-Filterresults: notjunk:1;V03:K0:L3pSAUZEaOQ=:spCTISMjNkRWj+YwzVao8U iiQwwpEOFTeSUSO9H1Aai6i3mvYIwDxNBv12L0g+rseMsaUfOdOeFV1o34GYeSAtNW3MZsbnO /u2B4BoBytxwKu7RTjrd3BbGe+N8N/7xiwSf6zmhsAI/eWwHX9pIOfLkhd76Dbx6rHlTZj9Kd XqPgeKLW2CEJaRAf6/UJ2k/nKlB5sdQNHNqRtIque99wU14hZw1afQFWAvO6xnLlaXxZt6jrb Clwyp9fipc8QwnQLqvkoJqMX1eUNaZsv1/ZfpALafeRWpvYey9HPILOvWxx21kQaRHZXP+R2O XLwk9OsSNZYbnzM8hJV06V7GjFVir6xrC7XkOB1MjIfEMRfYTcPCK69eUWGwfItFswMLE6SZP NweALUA4TAhVTdUlANPUJm9guFB7MLNi9bovtVJZxZQrP4m8rUHwCvibyssCauZwWZtDMO1CQ Cq8jz5+/zqulP4VgWInC1WbiWLVtsvi8f3MkYPw3FzN1qbnWXtDA/DkUM8E7ITRvtMTjmgAi7 I7vxT9jkx9Xtyp73xy6ZbBNwyDu3QxRksR5SaO0rfhB3QrlUm9kV22ytajUjepPAToAtde5YE C8ctPlEwRqhBeUm7i2aiSZd5+v06DofrOYrHrAnmBrGSYs0Hn9n+ZPyeHqx/J0pn9rPGpvynw A1VGAnZdOantQCBPOoIedq/x19HY1oZm4Wng+1odzwwN1HxDORitaKP3p/nN5RAjNT2mEJUSj k6YcPs8ZWKIDz9uJgdYHKH8Y8l+bWtPh83/zRPjt6UCOSqDVQLeW4z+5i2GsgGuPT+4eSN+Oi wyDZm6uvPfqgoCkdTpYv6r8egaDORYaatRmzd39P+CF0rWRhy72Z0Fx4x0/3kQw+R5F+CyKhx ixRnkGLoMoZzC6Na6UtbSdWBoGBj6MNJYuWpuM10FzhFqLQZjLnTHbAG6X0HhGBTGanTzwI6t yeTn7h0RKljSebqls2NZ+i3k60T1mai6OYzWhtqvfQoA0MnOKE59u8zrHwy/HN1yZd8FaYcl/ BbYAutJ4QYfvJiJamJJ3G3UWYEL19I3eHNfVWdv7KlVaVa9KKNFCQSkFs97sv4XuNkGeGM52P oSN0vTWNXpE39Ipd2DqxSUePG9j7tzhEPudbCvIhi6Dm1Ob61I82cFmMecX22znsU4uX95VXJ NgHsIf50cF8+1qgLgLth9v8nGMO1NLZpdZu7Hg7RUL4yJnM2luXx4I2QmV27B6cZkCawg= X-Spam-Status: No, score=-25.4 required=5.0 tests=DKIM_SIGNED, DKIM_VALID, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 17:46:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RVe1B4LtKIapFERFEmoxrJenyhil7SAQy Content-Type: multipart/mixed; boundary="rgvVily4ExjdDiDVKqS1SwSgSTGVzQKki"; protected-headers="v1" From: Kamil Rytarowski To: Simon Marchi , gdb-patches@sourceware.org Message-ID: <72744690-5add-413e-a4cf-ada6cf8bd5e9@gmx.com> Subject: Re: [PATCH] Return unconditionally ptid.pid () in get_ptrace_pid() for NetBSD References: <20200317163020.28790-1-n54@gmx.com> <597c7d5f-dfd5-53a8-3369-4042d4cd653a@simark.ca> In-Reply-To: <597c7d5f-dfd5-53a8-3369-4042d4cd653a@simark.ca> --rgvVily4ExjdDiDVKqS1SwSgSTGVzQKki Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 17.03.2020 17:39, Simon Marchi wrote: > On 2020-03-17 12:30 p.m., Kamil Rytarowski wrote: >> NetBSD tracks the PID and LWP pair separately and both values are >> needed and meaningful. >> --- >> gdb/inf-ptrace.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/gdb/inf-ptrace.c b/gdb/inf-ptrace.c >> index db17a76d946..6a6cb554ba7 100644 >> --- a/gdb/inf-ptrace.c >> +++ b/gdb/inf-ptrace.c >> @@ -321,10 +321,14 @@ get_ptrace_pid (ptid_t ptid) >> { >> pid_t pid; >> >> +#if !defined(__NetBSD__) >> /* If we have an LWPID to work with, use it. Otherwise, we're >> - dealing with a non-threaded program/target. */ >> + dealing with a non-threaded program/target. >> + >> + NetBSD tracks the PID and LWP pair separately. */ >> pid =3D ptid.lwp (); >> if (pid =3D=3D 0) >> +#endif >> pid =3D ptid.pid (); >> return pid; >> } >> -- >> 2.25.0 >> >=20 > I think you should just avoid using get_ptrace_pid on NetBSD altogether= , since > it is meant for OSes that require passing a single thread identifier to= ptrace > (whereas NetBSD requires the (pid, lwp) pair). >=20 > Even with this modification in get_ptrace_pid, you need to change all t= he ptrace > call sites to pass the lwp on top of it. >=20 > I would suggest to instead #ifdef out get_ptrace_pid entirely on NetBSD= , to avoid > using it by mistake, and just replace all ptrace call sites possibly us= ed on BSD > to be >=20 > ptrace (request, ptid.pid (), addr, ptid.lwp ()); >=20 > This matches what I suggested in: >=20 > https://sourceware.org/pipermail/gdb-patches/2020-March/166735.html >=20 > Simon >=20 Avoiding is possibly nice.. however in the current code it is much more intrusive. We would need to patch now generic and OS/CPU specific code (some of that is also shared with other OSs due to legacy reasons). I think it is much cleaner to return ptid. pid() for NetBSD and reflect the meaning of get_ptrace_pid(). If I follow your advice I end up with ifdefs like here: diff --git a/gdb/inf-ptrace.c b/gdb/inf-ptrace.c index b63a1bf88ef..a5d9c1d10ea 100644 --- a/gdb/inf-ptrace.c +++ b/gdb/inf-ptrace.c @@ -349,7 +349,11 @@ inf_ptrace_target::resume (ptid_t ptid, int step, enum gdb_signal signal) single-threaded processes, so simply resume the inferior. */ pid =3D inferior_ptid.pid (); else +#ifdef __NetBSD__ + pid =3D ptid. pid(); +#else pid =3D get_ptrace_pid (ptid); +#endif if (catch_syscall_enabled () > 0) request =3D PT_SYSCALL; @@ -533,7 +537,11 @@ inf_ptrace_target::xfer_partial (enum target_object object, const gdb_byte *writebuf, ULONGEST offset, ULONGEST len, ULONGEST *xfered_len) { +#ifdef __NetBSD__ + pid_t pid =3D inferior_ptid. pid(); +#else pid_t pid =3D get_ptrace_pid (inferior_ptid); +#endif switch (object) { Maintaining that will be certainly harder and it will be prone to recurring regressions. If we want to take the route of cleanups and refactoring I think it would be better to rethink the pid,lwp separation in Linux; but that is much beyond the scope of my patches. Last but not least, get_ptrace_pid() would work now for NetBSD literally as specified in the function name now... just extracting pid from ptid, not calculating it from lwp/pid. It's now questionable whether a wrapper function is still needed, but that would be optimized to .pid () in futur= e. --rgvVily4ExjdDiDVKqS1SwSgSTGVzQKki-- --RVe1B4LtKIapFERFEmoxrJenyhil7SAQy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAl5xDMYACgkQS7MI6bAu dmylTw/+JOXk/NMMRzt1gf6DQtm01nXoKv8dev+/2osISWSM136KAR5kdmNIx4Z+ k37CalWlFkZ0YsM5L113yCcl9FtwtoiFka6vazUqSC/TN0oJ7ZkVZhqwREU1TpWZ 7t0tngXp0L1IJBB5reYKYb3uIjDrqFlTSMbRQSykak6QaKGlyLO8LQQmFc+Qm2dr 7YJe83CCjQsgloaJVaXE+zFI1GgeNlRDmt8vHxL06YHTG9FHxlEJyAI9VJkCzGv9 mNbJ77GbSuWduVl3WmLQn0ec1nlILGFqL9ukSeM3wkvHruNQRgPcW5IglSG3mBQ4 /0hY9/mQOQgB+fVkAGldZUsRC9MNkBganj9oh2p++g7JqLILxZhBjzaNv7NASRux et+7RooMfuRWZ+wDwD8B9kxw84Oc2qsPlKHcXfRHh/YQxCHvkRUip8T4WBKhTNlh 1o/5Te44pBbRzgU6JFvpXme2DlD3PUgZ5nmwkeh0jbvS6fgLkGu73VtaMsWBitRN MPOQVq7GD2zfj67kHv95IXawl58VzUgekpwa8TR2Zp/0ilUs/WzEwBjUGw9sKHop wpULdAWIHDWg4+3pK2zqFG/kvYs3FkSmJSptf2MyK1tjZqkeiBpAd5EsnXgc7iZU j8VmCzMB08Qyv7m9AWvzQM3wAcWFwcDa7W/ysJ6zzpw5gn2g0lQ= =BC2w -----END PGP SIGNATURE----- --RVe1B4LtKIapFERFEmoxrJenyhil7SAQy--