[I changed subjects, this thread is too long]

> On Mon, Apr 28, 2003 at 12:37:12PM -0400, Andrew Cagney wrote:
> 
>> Hmm, I think it will be needed anyway, what happens when the user is 
>> debugging an i386 mode function (with 32 bit register based long long 
>> debug info) on an x86-64 target?  That's the MIPS problem, and it needs 
>> that projection(1).
>> 
>> Also, the next_regnum method assumes that all debug infos use the same 
>> register sequencing.
>> 
>> A word of caution though, the projection, at the register level works. 
>> Frame's might need tweaking.  The alternative is to start out with 
>> deprecated_next_regnum so that it is clear where this stands.
> 
> 
> Here's a discussion piece.  I've implemented your suggestion.  Two
> notes:
>   - Having done it, I still don't like it :)  Using the register cache
> in this way seems very wrong to me.

Got another way of getting  MIPS (32 on 64), i386 on x86-64 (or even 
ia64?), e500 on PPC, sh4 on sh64, ... all working?

>   - It doesn't work for frames, because by the time
> i386_pseudo_register_read is called the regcache is always
> current_regcache.  I believe this is because of
> legacy_saved_regs_prev_register:
> 
> 975       if (get_frame_saved_regs (frame) != NULL
> 976           && get_frame_saved_regs (frame)[regnum] != 0)
> 
> I guess doing this much without doing the rest of the conversion makes
> the frame machinery quite sad.

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.

Andrew