Re: parcelling up struct gdbarch

[Andrew Cagney <ac131313@cygnus.com>]

>> If raw registers are given names independant of the user visible cooked 
>> registers then, something as silly as:
>> 
>> 0:gpr0,4;1:gpr1,4;4;3:spr0;8;4;...
>> 
>> would even work.
> 
> 
> I don't understand why you say that we would need more than one
> G-packet format per gdbarch.  Why?  Compatibility with different stubs?


To remove the need to recompile GDB every time someone wants to get GDB 
to talk to a stub.  Instead of having to incorporate C code for each and 
every MIPS g-packet format, a simple generic table.  If the user finds 
their packet isn't included then just specify its layout on using the CLI.


> That seems like the wrong approach.  We've currently got one G-packet
> format per definition of the register cache, and we've got one of those
> per gdbarch, right?


Why should the entire register cache get re-structured everytime someone 
tweeks the architecture.  It is what GDB currently does, I don't think 
it is right.


> I don't really understand what you mean by that string, either what the
> fields or supposed to be or what it is supposed to define.


g-register 0 is 4 bytes and gets written to gpr0.
g-register 1 is 4 bytes and is written to gpr1
there is a gap of 4 bytes
g-register 3 is 8 bytes and is written to spr0
.
.
.