Re: ARM and virtual/raw registers

[Andrew Cagney <ac131313 at cygnus dot com>]

> GDB has three main vectors, but only two are interesting in this case (the 
> third being the UI).  The target vector is the lowest level, it provides a 
> virtual abstraction of the processor -- registers, memory etc and methods 
> for recovering/changing their contents and generally manipulating the 
> machine (stepping, breakpoints, etc).  The target vector should present a 
> substantially uniform view of the processor regardless of the method used 
> to connect to it.  Putting it another way, the target vector presents 
> substantially the basic programmers' model of the CPU to the debugger.
> 
> The gdbarch vector is, effectively, the ABI model applied to that virtual 
> machine; it covers the mapping rules that were used by the compiler when 
> it produced the machine code for the user's program: procedure call 
> standards, layout of record types, symbolic information etc.  It knows, 
> for example, when a double for the variable X is in register F0: it 
> doesn't want to have to worry about how F0 is being recovered from the 
> physical machine -- in particular it doesn't want to know about how that 
> might vary across the various target connections -- that's the 
> responsibility of the target vector.

For registers things are currently closest to:

	debug register
	-> gdbarch_register_{read,write}
	-> regcache_{read,write}
	register-cache

In a sense gdbarch_register_{read,write} serve double duty - both 
mapping an ABI onto an ISA and handling target/ISA variation.  I think 
you're proposing that the ISA variant part be separated out with:

	-> target representation
	target

below the register cache.  I'm assuming that the ABI->ISA part remain 
and that there still be several ``ISAs'' - 32 / 64 bit MIPS, 26/32 Arm, ...

> As to whether the sim or remote targets can be made to support this model 
> cleanly, I'm not to worried about sim -- we can always fix this in 
> sim/arm/wrapper.c, the layer that interfaces between gdb and the simulator 
> so that it presents the virtual CPU model directly.  I don't know enough 
> about remote.c at this time to know what the problems are there, but I 
> suspect that this one will be the least of my worries when I want to start 
> adding support for the banked registers as well.  However, if these 
> targets can't present the processor abstraction cleanly, then they are 
> technically broken ;-)

The remote target is more than technically broken.

GDB is a slave to the remote protocol.  The remote protocol is what 
decides the layout of the raw register cache and that cache layout 
depends on what ever the remote target and GDB once, long ago, 
co-conspired.  You can't touch the raw registers without breaking GDB's 
ability to debug a remote target.  The MIPS, for instance, has more 
remote protocol formats than I've had hot dinners.  Every different MIPS 
configuration has a different, hard wired, remote protocol register buffer.

BTW, the reason I mention i387-tdep.c is that I think it is an example 
of where target side manipulation can go wrong.  The i387-tdep code 
doesn't just massage values, it instead completly re-orders the register 
cache so that it contains the registers in i387 stack order.  That, in 
turn, lead to all sorts of bugs when trying to save/restore the i387 
registers.  If this were re-implemented today, I think it the register 
buffer would be would left in i387 save order, instead using 
register_{read,write} (they were not available at the time).

I think, under your model, this would be flaged as a no-no - there being 
no technical reason for laying the registers out in a way other than 
according to i387 save order.

enjoy,
Andrew