Re: re-ordered i386 regcache

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, Apr 28, 2003 at 10:15:03PM -0400, Andrew Cagney wrote:
> 
> >>>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.

Sure.  That's why I'm trying to get a grasp on what you think the real
issue is.

> >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?)

Absolutely.  I know the e500 situation (limited form of DW_OP_piece for
64-bit registers), and both MIPS/MIPS and x86-64/i386 are trying to
expose the same register in multiple ways.

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

If the choice is:
  - contain an i386 specific problem to i386 specific code by using a
    hack
  - provide a general, well-defined mechanism that at least now we only
    need for i386
then I'm all for plan B.

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

Not familiar with the SH code... skimming the e500 code I can't quite
tell how it works, but it looks as if the pseudo registers are found in
get_frame_saved_regs and e500_pseudo_register_read will only behave
correctly for the topmost frame.  Which makes sense given the way we
handle e500 regs.

I suppose I could mark both versions of %eax saved in i386's
frame_get_saved_regs to fix the immediate problem...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer