In theory (and emphasis on the theory) things need to be changed so that:
- 32 32 bit nameless pseudo-registers are added to the cooked register space
- the 32 64 bit gprs get given a 64 bit virtual type so that they have
identical raw and virtual sizes
- The debug info, for a 32 bit ABI, maps the gpr register numbers onto
the 32 bit pseudo register range
- The gdbarch pseudo register read/write function maps the 32 bit
pseudo-registers onto the 64 bit gprs.
- For init saved regs, dependant on the size of the register saved,
either the the address of the 64 bit GPR or the address of the 32 bit
pseudo-register is set
- a custom mips register unwind function maps the requested register (64
bit gpr or 32 bit pseudo) onto: the 32 bit pseudo, the 64 bit gpr, or a
further recursive unwind call. If it has to do a 32/64 mapping then it
sets not-an-lval.
- you find you have to yank all sorts of register converible code
But like I said, it is theory, the mips suffers from one hack (like the
above) piled on top of another (the register convertable stuff, the
register raw/virtual size being different, ...). I don't know if now is
the time to be experimenting with theories :-)
Yes, fixing all of the above is quite a lot more work than I have time
for at the moment.
But, assuming that my rewrite is functionally equivalent to the
original, what is the reason for preferring to inline
find_saved_register() over using the new interface?
Until the MIPS is ready, I think it is better to keep it and the unwind
code well separated. We otherwize run the real risk of having
unwind/cfi changes going off the rails because they break the (already
broken) MIPS.