Re: re-ordered i386 regcache

Daniel Jacobowitz
2003-04-29T04:45:17Z

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