From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19183 invoked by alias); 24 Jan 2020 16:37:06 -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 19175 invoked by uid 89); 24 Jan 2020 16:37:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-20.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Jan 2020 16:37:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1579883820; bh=6MnW98bCZ8w6V/GOBWmSYy+2LJsgv1BHTr2Mf5aJ7QM=; h=X-UI-Sender-Class:To:Cc:References:From:Subject:Date:In-Reply-To; b=IUCogC2H9tWRNTQ4EVZCD6R4y00umVmXkI9o00Vsbz3oBlWeWIXAKaF/x76NDVLpB wvt2CssVGjECfWXb9LHRf0oFQsimg7049YIBis0MvhNOaJf54AlWdxEgQDOhmZx9i4 fL8mIwRIq0nC/uwHBGArkVj+77oS+k2/ZkDaqnKM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.0.241] ([89.71.135.231]) by mail.gmx.com (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MTAFb-1j1zqF1OTH-00UZy8; Fri, 24 Jan 2020 17:37:00 +0100 To: Christian Biesinger Cc: gdb-patches References: <20200124141458.171392-3-cbiesinger@chromium.org> <20200124141818.172490-1-cbiesinger@chromium.org> <2afe5687-5be2-7650-d4e3-3aceed3f68f2@gmx.com> <7432896e-39ec-4a99-cc07-77c684b71644@gmx.com> <8126c811-3416-a4d4-5a01-17776b0df999@gmx.com> From: Kamil Rytarowski Subject: Re: [PATCH 2/3 v2] Define _KMEMUSER in arm-nbsd-nat.c Message-ID: <7a00a471-ab23-a235-d9bb-1d5d574bdacd@gmx.com> Date: Fri, 24 Jan 2020 16:45:00 -0000 User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rH9mA9N1Zpvbyw4uMfDyq2YBHPZvbfNDB" X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00815.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rH9mA9N1Zpvbyw4uMfDyq2YBHPZvbfNDB Content-Type: multipart/mixed; boundary="aTcHxtzuAy8sb1TTDpXbZsBEtzjIXW0F9"; protected-headers="v1" From: Kamil Rytarowski To: Christian Biesinger Cc: gdb-patches Message-ID: <7a00a471-ab23-a235-d9bb-1d5d574bdacd@gmx.com> Subject: Re: [PATCH 2/3 v2] Define _KMEMUSER in arm-nbsd-nat.c References: <20200124141458.171392-3-cbiesinger@chromium.org> <20200124141818.172490-1-cbiesinger@chromium.org> <2afe5687-5be2-7650-d4e3-3aceed3f68f2@gmx.com> <7432896e-39ec-4a99-cc07-77c684b71644@gmx.com> <8126c811-3416-a4d4-5a01-17776b0df999@gmx.com> In-Reply-To: --aTcHxtzuAy8sb1TTDpXbZsBEtzjIXW0F9 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Content-length: 5742 On 24.01.2020 17:01, Christian Biesinger wrote: > On Fri, Jan 24, 2020 at 4:49 PM Kamil Rytarowski wrote: >> >> On 24.01.2020 16:35, Christian Biesinger via gdb-patches wrote: >>> On Fri, Jan 24, 2020 at 4:23 PM Kamil Rytarowski wrote: >>>> >>>> On 24.01.2020 15:53, Christian Biesinger via gdb-patches wrote: >>>>> Hi Kamil, >>>>> >>>>> I have a related question. NetBSD applied this patch: >>>>> https://www.mail-archive.com/tech@openbsd.org/msg44100.html >>>>> >>>> >>>> Is this the right link? >>> >>> Yeah -- that patch changes a system header at the top and patches GDB >>> at the bottom. >>> >> >> This is not a change in NetBSD, so it is unrelated. >=20 > My apologies, I completely misread that. I'll see if I can find where > NetBSD changed their FP register data structure, or perhaps your > downstream patch will still work (although that probably has to come > from one of y'all for copyright reasons?) >=20 Please cherry-pick what you need and I will find the original author. Many people in NetBSD have FSF papers done. >>>>> Do you know which NetBSD version that shipped in? Can we apply that >>>>> patch to GDB as-is or should we attempt to support the older struct >>>>> layout as well? >>>> >>>> Please go for the current FPU layout on NetBSD. Massive ptrace(2) fixes >>>> were introduced in NetBSD-8 and later. Soon NetBSD 7.x will go EOL >>>> (after releasing 9.0, rc2 is planned soon). >>> >>> OK, great. Thanks. >>> >>>> In LLDB we support NetBSD 9.0 or newer. In GDB we should keep the same >>>> minimal requirements and deal with older NetBSD versions (if at all) >>>> with downstream patches. >>>> >>>> We have got a pile of local GDB patches. >>> >>> OK. Maybe I should look through those at some point... I was >>> surprised that NetBSD apparently has an oldish GDB if >>> http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/gdb/README.html >>> is correct (8.1) >>> >>>> There is also a functional gdbserver implementation on NetBSD/amd64 and >>>> I intend to upstream it. (Help wanted! Would you be interested in this >>>> and in upstreaming?) >>>> >>>> The patches are located here: >>>> >>>> https://github.com/NetBSD/pkgsrc-wip/tree/master/gdb-netbsd/patches >>>> >>>> * with core/basic features... but it is difficult as there is no OS wi= th >>>> finished transition... >>>> https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity >>> >>> I can definitely not commit to upstreaming the gdbserver. I am only >>> looking at NetBSD because I wanted to remove a deprecated function in >>> GDB, and one of the two callers is in NetBSD ARM code. So, I wanted to >>> build ARM NetBSD first so I can test if it still works after that >>> change. But I can't commit to any further NetBSD work. >>> >> >> OK, thanks! >> >>> BTW, is there a reason why your patches have one .patch per changed >>> file? I usually find it easier to follow them if they are instead >>> grouped by some kind of topic per patch. >>> >> >> This is a convention in pkgsrc and it is practical for its use-case. >=20 > OK. Some of those patches should be upstreamable very easily. For some > others it would be helpful to have a description & I guess a copyright > assignment. >=20 My intention was to revamp the general NetBSD support from native-only to gdbserver... (same like lldb-server).. and it would result in deep rewrite of the current code, but there is work in progress status in Linux so it does not help. > I also noticed that some of those files are 0 bytes and could probably > be deleted? And this does not seem necessary: > https://github.com/NetBSD/pkgsrc-wip/blob/master/gdb-netbsd/patches/patch= -bfd_netbsd-core.c >=20 Good catch. >>>>> >>>>> Thanks, >>>>> Christian >>>>> >>>>> On Fri, Jan 24, 2020 at 3:29 PM Kamil Rytarowski wrote: >>>>>> >>>>>> On 24.01.2020 15:18, cbiesinger@chromium.org wrote: >>>>>>> From: Christian Biesinger >>>>>>> >>>>>>> Fixes the below compile error on ARM NetBSD 9.0_RC1 (the only versi= on I >>>>>>> tested). types.h does not define register_t by default. >>>>>>> >>>>>>> We already use this define elsewhere, notably in bsd-kvm.c. >>>>>>> >>>>>>> In file included from ../../gdb/arm-nbsd-nat.c:28: >>>>>>> /usr/include/machine/frame.h:54:2: error: unknown type name 'regist= er_t'; did you mean '__register_t'? >>>>>>> register_t tf_spsr; >>>>>>> ^ >>>>>>> /usr/include/machine/types.h:77:14: note: '__register_t' declared h= ere >>>>>>> typedef int __register_t; >>>>>>> ^ >>>>>>> >>>>>>> There are other compile errors that this does not fix. >>>>>>> >>>>>>> gdb/ChangeLog: >>>>>>> >>>>>>> 2020-01-24 Christian Biesinger >>>>>>> >>>>>>> * arm-nbsd-nat.c: Define _KMEMUSER to get the declaration of >>>>>>> register_t. >>>>>>> >>>>>>> Change-Id: I82c21d38189ee59ea0af2538ba84b771d268722e >>>>>>> --- >>>>>>> gdb/arm-nbsd-nat.c | 2 ++ >>>>>>> 1 file changed, 2 insertions(+) >>>>>>> >>>>>>> diff --git a/gdb/arm-nbsd-nat.c b/gdb/arm-nbsd-nat.c >>>>>>> index 00f919194b..4844b51a3c 100644 >>>>>>> --- a/gdb/arm-nbsd-nat.c >>>>>>> +++ b/gdb/arm-nbsd-nat.c >>>>>>> @@ -17,6 +17,8 @@ >>>>>>> You should have received a copy of the GNU General Public Licen= se >>>>>>> along with this program. If not, see . */ >>>>>>> >>>>>>> +/* We define this to get types like register_t. */ >>>>>>> +#define _KMEMUSER >>>>>>> #include "defs.h" >>>>>>> #include "gdbcore.h" >>>>>>> #include "inferior.h" >>>>>>> >>>>>> >>>>>> While gdb is the right user for _KMEMUSER, here we should probably go >>>>>> for -D_KERNTYPES as it is the canonical symbol for register_t. >>>>>> >>>> >>>> >> >> --aTcHxtzuAy8sb1TTDpXbZsBEtzjIXW0F9-- --rH9mA9N1Zpvbyw4uMfDyq2YBHPZvbfNDB 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----- iQIzBAEBCAAdFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAl4rHP0ACgkQS7MI6bAu dmxl+g/8CXCUKT9dniOD/DFaTlBFNKNt+5WhTtpQFdTeelCJhRCwtr3KBHVeke/P n/OHHFP6E5vfL1ALteK4DYNTjfAogbF6xoxjihjz7JFCP2ohuqCHxKPGK4JI+Ci0 n7VaDeoWCR4S6L+qRH4W+pgICdioEbSzpRMyQkTGoGgSqRDeAUfyu/pkcCfDDItH PWCLvkHeUA7HQXZs8cnSE13T+ZtP7/NjB0VmiMUx3huTPGP9zrp68JUHM9IhpeeX sAYuqOQdsllm4MDhsDJu3TMYeSdbETmHkXCk1qYI9XcISjdH9l9gI7U233zORuv+ nPwOzWH0Kl6yl0Iox8S1KMbvyrC74TDgJERSzY2IogPD8yBx6LZJBCkx1MTAdOnJ KHbiVaLIGDbjbgwV9Cl/WjMCbprNYxK6fyuRL5CqoPVW1spCqx6+DxbTPX/GP0Eo MNShQgztYFGSGFPRe+n+hEXA3Cpn9kjjIW5XYHqvscpbufaGezJuUhxrEa4ogfkZ W49pbp/H1xJLYDE7Ld/htT6TzRHg3TiHRq5YcwcdsrR6xBsxr46wNfvuK5ZVpfXj paoJ6b+l8/8irWe1p6lUgUOY/nj4y51mnhBEqj0EXrGLSQRrX3VPuXSQBt10Fz6V gr9o/Lmemv8133HcN6HvoZpis+bog4nrBhElg6kUjPYczR+Pdy0= =EaBf -----END PGP SIGNATURE----- --rH9mA9N1Zpvbyw4uMfDyq2YBHPZvbfNDB--