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: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 11 Jul 2001 16:44:28 -0400
- 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>
>
> As Andrew observes, you'll probably get tangled up in dependencies,
> but those are likely to be mistakes in GDB's architecture - there's
> no good reason why lowest-level native and target support (which is
> all that gdbserver needs) has to be making references to user-interface
> code and the like.
Just FYI, it isn't just multi-arch. ui-out/ui-file/.... are also having
an impact effect. In their case a little re-aranging would certainly
help (create cleanups.[hc]?, file-utils.[hc]?, ...).
> Thought 1: split the arch vector into a general vector and a nano-vector
> with only the register definitions and such. If we really don't care
> about the extra footprint from unused arch code (either because it's
> small, or we know linker will discard), then instead you could have
> an optional <arch>-ui.c to be a home for target-specific commands.
Here, I think trying to split things up would be roughly equivalent to
re-aranging those brand new deck chairs(1) :-) This is because
everything depends on the single macro REGISTER_RAW_SIZE(). As I noted
in another e-mail, I think there needs to be something that specifies
the protocol register numbering [rawnum] and the G packet layout that is
completly independant of multi-arch and, for the G packet, GDB.
On a normal GDB, the conversion sequence:
nat-register layout
|
|(*-nat.c)
|
raw register layout
|
|(*frame*)
|
cooked register layout
occures. (nat layout is what is on the HOST OS IF, raw layout is what
is used by GDB's register cache and target vector, cooked layout is what
is used by read_register_frame(frame, ...) et.al.)
If you introduce the remote protocol into the picture then the sequence
is changed to either:
nat-register layout
|
|(gdbserv/*nat*)
|
G packet layout
|
|(remote.c)
|
raw reg layout
|
|(*frame*)
|
cooked reg layout
or
nat-register layout
|
|(*-nat.c)
|
raw register layout
|
|(gdbserver)
|
G packet layout
|
|(remote.c)
|
raw register layout
|
|(frame*.c)
|
cooked register layout
depending on how ``pure'' you want things :-)
Anyway, within the above, I think the `G packet' and possibly the `raw
register layout' need to be defined out side of *-tdep.c. If this is
done then the rest of the problem becomes managable.
See also:
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=122&database=gdb
Anyway, to throw a spanner in the works, (given some comments from Eli)
IRIX could easily end up with a *-nat.c that supports two different
architectures. Solaris is similar. I suspect the i386-64 chip could be
the same.
enjoy,
Andrew
--
(1) Rearanging deck chairs on the titanic.