Re: re-ordered i386 regcache

[Andrew Cagney <ac131313@redhat.com>]

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

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

> then I'm all for plan B.

Seems we've each taken to calling the alternative solution ``a hack'' :-(

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.

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

Andrew