From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34756 invoked by alias); 17 Apr 2018 18:50:01 -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 33247 invoked by uid 89); 17 Apr 2018 18:50:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=progress X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Apr 2018 18:49:58 +0000 Received: from [192.168.0.241] ([89.78.252.225]) by mail.gmx.com (mrgmx102 [212.227.17.174]) with ESMTPSA (Nemesis) id 0LlGoc-1eXo0g3Jos-00b72P; Tue, 17 Apr 2018 20:49:48 +0200 Subject: Re: [PATCH 31/40] target_ops/C++: Base FreeBSD target To: Pedro Alves , John Baldwin , gdb-patches@sourceware.org References: <20180414190953.24481-1-palves@redhat.com> <20180414190953.24481-32-palves@redhat.com> <2651054.rGX2nUqyEc@ralph.baldwin.cx> <4c3b320e-ecbe-4e97-9ee4-91cacca60b8d@redhat.com> <44d9588c-e23e-5ef5-ef62-fdd594dd4c7f@redhat.com> From: Kamil Rytarowski Message-ID: Date: Tue, 17 Apr 2018 18:50:00 -0000 User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <44d9588c-e23e-5ef5-ef62-fdd594dd4c7f@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nGJLFb6P0fwIXe6stUjA0wJodipoWxQPC" X-UI-Out-Filterresults: notjunk:1;V01:K0:6TJAOpo7gM8=:itWrD5lvj3hzG+ule1DRx3 ElQ37iHGP3XdRCn4D1JJxq6Y5NMz4RtJGO6VjuP6K4ng7eA3+ReAiF8IepxANorFu7o0qRohS jkdxthfCvW1T/brDx7MceJds7oMXrH0iX59fgWGlYaJYAXNyfxFI89bi6fJ3VNk2u8CiwMNgw y5jAvPdrM0M1rXd3IDsgCnPtxjUwAV+UZ6lGBehG1c7uvGUsqhMOEnQCr9k8Trxg/FuMnz7Nq vyjVEzB4Vm2wY9Hqz6K63X2IiXSvej4BkA4/e6Ab3P7uxb02c/HPeX3T+cnT3f0ecA6OrKDcd 66NZMjbGfL2j5BL9tPycHny/leuV1EXUx7DXXETd2B+K8YUcvYJzX3wJf4gVg25OiaUJpJKkz mBNmF38kY5JiLEJdycO60De0yWeUzf2manVK0xtXTh5E6PipnHT5m7dkTktChUR7HqUz843Ih emreWnurHW7kJ7wpQaLdfaKutQk6CZVP1egeTVYtLV20vjTuzfyPS0RhATl04fED2NQpC7BRI WSxYWqea6CejsoU3XcHGjYGxFMPeYRGrlo1C7qNUuytbX1ylFfwjwpABhhV4ISDlImDDLLaLG F8jDNs0uZeFzlO3aUwgfG8G7SrqTMe+YLhJtrfU5THIgUeNiUgQRa5WsX+AJNvFlitGqlqbFJ 5hOxvzWojrUSebHKSqpGFOqYkui7Uvcu5oN7taEXrYSwPwW2uMMgOzI/IIpkQXPpcKd41XSz2 XqqyUSsKGZSM3pyrpiZPfwMr/3wPQAvFdBet2XJCWN3ezEpY8nRH2QMruwB0iC4BS5AEowKSz e+GKBohG66MU0XpX3a+BiP8f5L2rw== X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00348.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nGJLFb6P0fwIXe6stUjA0wJodipoWxQPC Content-Type: multipart/mixed; boundary="Nk4ForVeHQ3anCTRSoG0IA9VNT1dwFSML"; protected-headers="v1" From: Kamil Rytarowski To: Pedro Alves , John Baldwin , gdb-patches@sourceware.org Message-ID: Subject: Re: [PATCH 31/40] target_ops/C++: Base FreeBSD target References: <20180414190953.24481-1-palves@redhat.com> <20180414190953.24481-32-palves@redhat.com> <2651054.rGX2nUqyEc@ralph.baldwin.cx> <4c3b320e-ecbe-4e97-9ee4-91cacca60b8d@redhat.com> <44d9588c-e23e-5ef5-ef62-fdd594dd4c7f@redhat.com> In-Reply-To: <44d9588c-e23e-5ef5-ef62-fdd594dd4c7f@redhat.com> --Nk4ForVeHQ3anCTRSoG0IA9VNT1dwFSML Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Content-length: 3738 On 17.04.2018 20:13, Pedro Alves wrote: > Hi Kamil! >=20 > Will you be able to smoke test the branch on your favorite > port? That'd be super. :-) >=20 I can try to test it on NetBSD/amd64. > On 04/17/2018 06:30 PM, Kamil Rytarowski wrote: >=20 >> Common BSD target should be changed in future to common BSD/Linux target >> like in LLDB. There is a shared Remote Process Plugin used by Linux and >> NetBSD. >=20 > I think that is confusing or oversimplifying things. Also, it's > a bit orthogonal to the present effort. :-) The "shared" Remote > Process Plugin is just the equivalent of "target remote" in gdb. >=20 My comment was rather orthogonal to the process plugin model. I wanted to state that FreeBSD and NetBSD diverged, while NetBSD was trying to follow FreeBSD / Linux API with a clean room design. Cloning 1:1: other BSD would require breakage in existing software as the APIs were already incompatible. For example PT_LWPINFO has a different meaning on FreeBSD (get thread info with trap details) and NetBSD (iterate over threads in tracee). This means that we are today a distinct target. It's an open question about OpenBSD, they could follow NetBSD with marginal differences... once we could convince them to sync up with proper support in debuggers. > See: >=20 > https://sourceware.org/gdb/wiki/Common > https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity >=20 > What we're missing is that gdbserver was never ported over to the > BSDs. At least, upstream. Just like in lldb not all ports > have been converted to use the remote process plugin. >=20 > Clearly there needs to be a shared interface the different target > backends such as BSD and Linux implement to interact with the > core of the debugger or the server. In gdb and gdbserver that is > their corresponding target_ops definitions (they're similar, but > not the same). So even when "going always remote", the target > backend implementations can well share code. >=20 > If you're considering porting gdbserver to some platform that > gdb already supports debugging natively, I strongly suggest > making gdbserver reuse the native target code in gdb instead of > duplicating the code. A few years back someone was working > on doing that for a Hurd gdbserver port, but unfortunately > the work was never completed. I was positively surprised how > little change the gdb code was requiring for gdbserver > adaptation though. >=20 > If done right (by making gdb and gdbserver use the same native > backend target_ops-like interface), there's nothing preventing using > the same backend code in-process in both gdb and gdbserver if we'd like, > instead of always forcing use of gdbserver behind the scenes. There > are advantages to supporting native-without-forcing-gdbserver > debugging too. It's all open in the air at this point. >=20 There was a port of gdbserver to NetBSD, perhaps so old that it's no longer relevant today (code from 2010). http://gnats.netbsd.org/43332 gdbserver for powerpc Right now, I'm busy with kernel work improving correctness of forking-like code in the context of debuggers, it will be followed by signals and threads. It's mostly a one-man show as of today... so it's a process taking time. I'm reporting the monthly progress on blog.netbsd.org. >> Enforcing a layer of common BSD code is counterproductive nowadays. >=20 > Note that nothing is being "enforced" and that there's no actual > "common BSD layer" in the sense that everything sits on top of some > common BSD layer. There are simply a few pieces of shared functionality. > If some BSD port doesn't want to use the shared bits, it's very easy > not to use them. >=20 It will be revisited in future. > Thanks, > Pedro Alves >=20 --Nk4ForVeHQ3anCTRSoG0IA9VNT1dwFSML-- --nGJLFb6P0fwIXe6stUjA0wJodipoWxQPC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 850 -----BEGIN PGP SIGNATURE----- iQJABAEBCAAqFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAlrWQkMMHG41NEBnbXgu Y29tAAoJEEuzCOmwLnZs5WgQAKBb+FeMaFh5I8x+1feNzBkfJ6mYREXdhV9cikCr Sx29zDYGQCnT78PPDfagKmmYX1n4joiG74Y4w3Rsh2tvEFGc5oq28mxFgf5z4FM2 09akSpsrqIDZP6lkvQZDRrBLjfIK8FrJhgO5lDqfCrSiOvf7BwfkcDBznKullhh2 y/BaFdqO7OOqNko1Jez7mMCaKv3FMTKzR3PB3WEY+KZodT40KqBBRN7UQTorTaaC vtyZRT1jE2I+sT173oK5xKrrfssQvxXi26iQ4azdxt9UTfB/kYeBExgLQPm8I31A f8EaF4qL0WkWqmMx5I/r/aghIqb/Ulf1fowRCMf1FHYaGFAZrWuVKfn/L+8Ci4Ws GLfy6AXk9xRjjbA5ozIXqfJHLQaUw5RC1unGWo2aq/o7tw86Tu7MtSyOcjnSAmOh QDU6Ofb0MeN3JmhWMRKtVjwPTujy/BIBuDvDvHHek7ebabz1NBEc+dVHuP3usYH2 uYFzh+09WUaUKbEr7MgBO7d1I37jHWfRpEguuIr8yTMoJZzlUtOoEYyqMNAgDLjQ mEFeM45V2YFm0oqROwKnSgnwKPYY0vLuXCm8yz0p+n3PAwxshOAnGv0mOcrB3gL/ yzh+MwWN/Yu31jBrfNkz9aAt3kqkWQ1+osV/8C/RXbdzzVOWrf8/hv7juqwV1aj2 wfoG =lO1M -----END PGP SIGNATURE----- --nGJLFb6P0fwIXe6stUjA0wJodipoWxQPC--