Re: [PATCH] Always include defs.h first.

[Joel Brobecker <brobecker@adacore.com>]

> One idea is to split at the target_ops level, where gdb's target_ops
> vector calls gdbserver's target_ops methods (bypassing most of "core"
> gdbserver code, RSP etc.)

"like" :-).

> But gdbserver's backends make use of e.g., breakpoints, behind gdb's
> back.  It may prove to be better to keep core gdb agnostic of this,
> and import gdbserver's breakpoints and regcache modules into gdb too
> (strictly for target side stuff), instead of adapting the backends use
> the main gdb's breakpoints list and regcaches.

This might need a little clarification when we get to it, because
I think we might be forcing stuff in gdbserver on some platforms
that would otherwise not need it. This could be an issue for platforms
where people are trying to provide as small a gdbserver as possible.

> I never liked the "common" moniker much.  It is a bit artificial and an
> artifact.  It tells us that the code is used by more than one something,
> but it doesn't tell us really what's inside.

I very much agree with this. I think it goes exactly in the same
direction as what Doug is saying, regarding modularization. If you
believe the LLVM documentation, that's one of the strong technical
elements in their design.

Going a little further, we could imagine that the remote protocol
being implemented as one or two modules. With a common target_ops,
and maybe a few other little modules that I am forgetting, we could
see gdbserver as being a few lines of code that glue the necessary
modules together.

This could be the beginning of GDB 8.0. It'd actually be so exciting
that I'd go straight to 10 and name it GDB X :-).

-- 
Joel