Re: Current (non-) state of gdbserver

[jtc@redback.com (J.T. Conklin)]

Daniel> Unless someone steps up with something already done (if you're
Daniel> out there, we're waiting...), I'm going to start working on
Daniel> this.  I'm not sure how multiarch will fit in to gdbserver in
Daniel> the future, but for now my intent is to bloat it somewhat with
Daniel> the necessary support code.  It'll probably involve splitting
Daniel> a lot of tdep files into two pieces.

Stan> As Andrew observes, you'll probably get tangled up in
Stan> dependencies, but those are likely to be mistakes in GDB's
Stan> architecture - there's no good reason why lowest-level native
Stan> and target support (which is all that gdbserver needs) has to be
Stan> making references to user-interface code and the like.

Stan> Thought 1: split the arch vector into a general vector and a
Stan> nano-vector with only the register definitions and such.  If we
Stan> really don't care about the extra footprint from unused arch
Stan> code (either because it's small, or we know linker will
Stan> discard), then instead you could have an optional <arch>-ui.c to
Stan> be a home for target-specific commands.

There are a small set of a primitives that GDB and gdbserver use to
control the target.  In GDB, they're scattered amongst *-tdep.c files,
inf*.c, etc.; while in gdbserver they are centralized in each low-*.c
file.  If we split a nano-vector out of the target vector, I think it
should contain only these functions.

Of the top of my head we have:

        * fetch/store memory
        * fetch/store registers
        * stop
        * kill 
        * resume
        * insert/remove break/watchpoint

While you're correct that most of the functions in *-tdep.c files
probably wouldn't bloat gdbserver too much if linked in, I prefer that
the split out files only contain the functions that implement the
nano-vector.  This delination clearly defines which functions go in
which file.

>> I'd also like to start building gdbserver by default on platforms which
>> support it (and I have patches to extend the list a bit).  That way we can
>> at least notice this sort of thing...

Stan> An excellent idea.  One thing I wanted to do as part of this was to
Stan> move gdbserver out of its subdirectory, since by the time you're
Stan> done integrating with the rest of GDB sources, you should only have
Stan> one file unique to gdbserver (main()), and the semi-duplicated
Stan> Makefile.in make trouble.

While we're talking of splitting things, I'd like to split things so
that gdbserver and the sample debug stubs shared as much as possible;
as well as making sure there are clean lines between the packet i/o,
command/response, and "nanovector" functions.  One complication is
that stubs have traditionally been public domain.

This would also make it trivial to prototype new high-level protocols
or data transports.

        --jtc

-- 
J.T. Conklin
RedBack Networks