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

[Pedro Alves <palves@redhat.com>]

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