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

[Pedro Alves <palves@redhat.com>]

On 11/08/2012 06:12 PM, Doug Evans wrote:
> 
> Another thing to consider:
> I'd like to move gdb to being more componentized (for lack of a better word).
> i.e., made up of application independent pieces.
> common/ is a minor step in this direction.

Yeah.  I recently wrote the below in an internal discussion.  Allow me to
just paste it here, as it just fits.  This was about the direction
of local/remote parity project once we reach a state where we can consider
reusing gdbserver's backend within gdb, instead of the
linux-nat.c/linux-low.c & friends duplication.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The division depends on how much of gdbserver we'd put into GDB.  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.)
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.

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.  IMO, it's not much different
from saying the gdb/ is the new common and allowing gdb/gdbserver/ to refer
to files under gdb/ .  In the extreme, we could end up with half of gdb
under common/ in a few years...  I was hoping we could so a better split,
say, start by putting the native target code (target_ops&friends) into
its own dir.  Or maybe call it "libbackend/"...

In any case, I think we have two kinds of "common" stuff.  There's the
native target backends (ptrace and friends), but there's also the
host side common stuff.  If you strip both gdb and gdbserver of their
native target backends (e.g, in gdbserver, you end up with "main()", command
line option processing, the event loop, the RSP mashalling, etc.., you'll
still find things that are common between the two programs.  The event
loop is an obvious example.  So it feels to me that we could take the
opportunity to do a better code division.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> Note that gdbserver doesn't have defs.h and lots of files in common/ do the

Well aware.  :-)

-- 
Pedro Alves