RFC: Optimization to write_register_bytes()
Fri May 5 13:04:00 GMT 2000
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
> 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:
> Modifying an mmx register may involve
> scattering values across both FP and
> mmpx specific parts of a buffer
> When writing back a SP it may need to
> both be written to both SP and USP.
More information about the Gdb-patches