Of the above, at least the e500 issues I consider to be completely
different; that's dealing with a very particular set of debug info that
only has part of the register. That's a handy thing to solve in the
register cache. Besides, it doesn't play sequential-register-numbering
tricks. That was the whole point - the other numbers are way off in
the 1200 range.
I'd say the MIPS/i386 issues are also more like e500 than like this
debug info ordering problem that we're talking about here.
Should there be a frame equivalent to the regcache's cooked->raw
projection? Should the read side of the cooked->raw projection be moved
to the frame?
Note that things like the m68hc11 some of the cooked registers are
mapped onto memory so the cooked->raw writes would likely still need to
remain.
Hmm, certainly something will have to change. Invoking
gdbarch_pseudo_register_read on the current regcache when we're
actually several frames away doesn't respond right. It seems to me
that moving the logic such that gdbarch_pseudo_register_read takes a
frame parameter might work better, but I'm not sure of the
implications.