Re: re-ordered i386 regcache

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Apr 29, 2003 at 10:30:03AM -0400, Andrew Cagney wrote:
> 
> >>>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.
> 
> The MIPS/i386 in the above be interpreted as i386 VS long long and not 
> i386/x86-64.  The reword below clarified it.
> 
> > 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.
> 
> All three require a projection such that, assumed contigious, debug info 
> registers project onto raw registers.  Isn't this what i386 has?

I don't think so.  All three need a view of registers slightly
different from the "normal" one, but they don't have "assumed
contiguous debug info registers".  In fact in e500 they're assumed
not-contiguous.

> >>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
> 
> You mean that the cooked->raw mechanism is a hack?

As I said above, the mechanism isn't.  This use of it is.

> >  - provide a general, well-defined mechanism that at least now we only
> >    need for i386
> 
> (and I'm calling it a quick and tempoary hack, because it isn't the 
> final solution)

Why not?  This is my view of the road:
  - If we have multiple parts reported for a variable's location, use
    that.
  - Otherwise if the variable fits in the reported location, just use
    that.
  - Otherwise, use a defined mechanism to guess where the next part is.
    Instead of assuming "oh, it's a register, the next part must be
    in register <this + 1>", which isn't true.  Instead of fudging the
    regcache using cooked->raw in order to make this invalid assumption
    appear true.

> GDB can't afford to accumulate yet more mechanisms just on the off 
> chance that a second architecture might just happen to need it.  This is 
> how GDB ended up with so many architecture methods used by 1 (then zero) 
> targets (what's the harm in #define ...; #ifdef ...?).  Instead, where 
> possible, target dependand code should start out by using existing 
> mechanisms; while the core is extended to use a more complete solution.

The "more complete solution" won't solve the problem for the debug info
we have today.  That'll be around for a very long time.  I'm more
worried about the fragility of doing complex things with the regcache,
which will have a maintenance cost every time we (you?) work on the
regcache.  When we could just do a simple method with low to no
maintenance cost.

Why _not_ acquire this mechanism?  There's only a problem with buildup
of not-thought-out and not-well-documented mechanisms, and this doesn't
have to be either.

> >I suppose I could mark both versions of %eax saved in i386's
> >frame_get_saved_regs to fix the immediate problem...
> 
> That is what was done (minus possible missed edge cases).
> 
> Being able to project cooked onto raw registers at the frame level, 
> should simplify this.

OK.  If I ever get frustrated/bored enough, I'll try to fix the patch I
posted.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer