This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Current (non-) state of gdbserver
- To: Stan Shebs <shebs at apple dot com>
- Subject: Re: Current (non-) state of gdbserver
- From: jtc at redback dot com (J.T. Conklin)
- Date: 11 Jul 2001 13:16:54 -0700
- Cc: Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>, gdb at sources dot redhat dot com
- References: <20010710234505.A5814@nevyn.them.org><3B4CA2DA.EB9DCB43@apple.com>
- Reply-To: jtc at redback dot com
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