[RFC]: Pseudo-registers for GDB

[Michael Snyder]

Eli Zaretskii wrote:
> 
> > Date: Tue, 11 Jul 2000 18:00:15 -0700
> > From: Michael Snyder <msnyder@cygnus.com>
> >
> > > Not really.  In the case in point, only 64 out of 80 bits are used in
> > > the MMX mode, while the FP mode uses all 80 bits.  It is not clear
> > > what to do with the rest of the bits when you are in the MMX mode.
> >
> > Well, but I mean, the raw form of the register that GDB sees
> > will be 10 bytes, right?  It's the virtual form that's 8 bytes?
> > Bottom like is, the MMX register and the FP register share
> > the same storage?
> 
> Yes, on all three counts.  The problem is how do you tell GDB that
> these registers share the same storage. 

Oh -- don't worry, just leave that to me.  I will publish
my suggested implementation soon, and then you can extend
or enhance it if needed.

> Various high-level layers of
> GDB are currently not ready for this situation.  You need either to
> invoke a target-specific function to update a register, or somehow
> communicate the fact that several registers share the same storage to
> the GDB application level, e.g. by letting the target or the
> architecture specify attributes of each register.
> 
> In other words, it sounds like a change in the way GDB represents
> registers is required.  We need a struct with attributes, pointers to
> aliased registers, overlap/offset info, etc.

Eventually that would be nice.  That's one reason why I've
extracted the register cache into its own module.  But I 
believe I can implement pseudo-registers without going
to such lengths.  Patience!  I was just sounding out the
idea...  You're gonna have to modify a lot of target tdep.c
modules which directly access the register cache data structures
before you can go to the lengths that you suggest.