Re: re-ordered i386 regcache

[Andrew Cagney <ac131313@redhat.com>]

>> >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?
> 
> 
> What problem besides the REGISTER_BYTE() problem are you solving with
> this mechanism?

REGISTER_BYTE() is a side issue.  It is eliminated with proper location 
support.

> 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.

(are you sure you're refering to the correct architectures here?)

> I'm not dismissing the value of the powerful pseudo technique that
> you've put together.  It's really handy.  I just don't think it's the
> answer to this problem.

Going back to an earlier point it contains an i386 specific problem to 
the i386.  That way yet another hack doesn't get in the core code. 
However, the knowledge of needing to handle that case does.

>> 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.

The e500 and sh both handle this by doing the maps on a per-frame basis.

Andrew