Re: [PATCH 31/40] target_ops/C++: Base FreeBSD target

[Kamil Rytarowski <n54 at gmx dot com>]

On 17.04.2018 20:13, Pedro Alves wrote:
> Hi Kamil!
> 
> Will you be able to smoke test the branch on your favorite
> port?  That'd be super.  :-)
> 

I can try to test it on NetBSD/amd64.

> 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.
> 

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:
> 
>  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.
> 

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.
> 
> 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.
> 

It will be revisited in future.

> Thanks,
> Pedro Alves
>

Attachment: signature.asc
Description: OpenPGP digital signature