Re: re-ordered i386 regcache

Daniel Jacobowitz
2003-04-29T15:08:20Z

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