Re: RFC: Optimization to write_register_bytes()

[Jim Blandy <jimb at zwingli dot cygnus dot com>]

Yes, yes, yes, this is exactly right.  Architecture-specific code
desperately needs full control over register references, and
introducing a standard interface is the right solution.

The challenge, of course, is doing this in a way that keeps the old
architectures/targets happy.



> The main objectives being:
> 
> 	o	a clear separation between the low
> 		level target and the high level GDB
> 
> 	o	a mechanism that solves the general
> 		problem of register aliases, overlaps
> 		etc instead of treating them as optional
> 		extras that can be wedged in as an after
> 		thought (that is a reasonable description
> 		of the current code).
> 
> 		Identify then solve the hard case and the
> 		rest just falls out.  GDB solved the easy
> 		case and then tried to ignore the real
> 		world :-)
> 
> 	o	a removal of the assumption that the
> 		mapping between the register cache
> 		and virtual registers is largely static.
> 		If you flip the USR/SSR stack register
> 		select bit in the status-register then
> 		the corresponding stack registers should
> 		reflect the change.
> 
> 	o	a mechanism that clearly separates the
> 		gdb internal register cache from any
> 		target (not architecture) dependant
> 		specifics such as [gG] packets.
> 
> Of course, like anything, it sounds good in theory.  In reality, it
> would have to contend with many<->many relationships at both the
> virt<->cache and cache<->target level.  For instance:
> 
> 	virt<->cache
> 		Modifying an mmx register may involve
> 		scattering values across both FP and
> 		mmpx specific parts of a buffer
> 
> 	cache<->target
> 		When writing back a SP it may need to
> 		both be written to both SP and USP.