Re: re-ordered i386 regcache

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Apr 28, 2003 at 06:52:05PM -0400, Andrew Cagney wrote:
> [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?

What problem besides the REGISTER_BYTE() problem are you solving with
this mechanism?

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.

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.

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

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer