Re: Current (non-) state of gdbserver

[Andrew Cagney <ac131313@cygnus.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.