From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117279 invoked by alias); 17 Apr 2018 18:13:57 -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 117240 invoked by uid 89); 17 Apr 2018 18:13:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 spammy=smoke, favorite, wiki X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Apr 2018 18:13:55 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DAF0281A88A6; Tue, 17 Apr 2018 18:13:53 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 32DDA7C37; Tue, 17 Apr 2018 18:13:53 +0000 (UTC) Subject: Re: [PATCH 31/40] target_ops/C++: Base FreeBSD target To: Kamil Rytarowski , 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> From: Pedro Alves Message-ID: <44d9588c-e23e-5ef5-ef62-fdd594dd4c7f@redhat.com> Date: Tue, 17 Apr 2018 18:13:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-04/txt/msg00347.txt.bz2 Hi Kamil! Will you be able to smoke test the branch on your favorite port? That'd be super. :-) On 04/17/2018 06:30 PM, Kamil Rytarowski wrote: > 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. 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. See: https://sourceware.org/gdb/wiki/Common https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity 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. 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. 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. 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. > Enforcing a layer of common BSD code is counterproductive nowadays. 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. Thanks, Pedro Alves