Re: [RFC]: Pseudo-registers for GDB

[Michael Snyder <msnyder at cygnus dot com>]

Eli Zaretskii wrote:
> 
> > Date: Mon, 10 Jul 2000 11:27:37 -0700
> > From: Michael Snyder <msnyder@cygnus.com>
> >
> > > However, there's one more complication that makes this feature hard to
> > > implement.  When several logical registers share the same physical
> > > ones, GDB needs to know which interpretation is currently used by the
> > > inferior.  Otherwise, GDB will attempt to write to the same storage
> > > twice, each time with different contents, because the application
> > > layer of GDB does treat all the registers as separate entities.
> >
> > The binary representation should be the same, right?
> 
> 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?

> But it gets worse.  Suppose the user puts certain values into the MMX
> registers.  If GDB maintains each register, even a pseudo-register,
> separately, it now has two different bit patterns for the same
> physical register.

But if GDB maintains them in the same storage, then it has
only one bit pattern.  The MMX pseudo-register would be just
an alias for the traditional, "real" register.

> Worse yet, GDB will actually try to store these values into the
> debuggee's registers much later, when the debuggee is resumed.  By
> that time, GDB will probably not know enough to decide which one of
> the two values (the MMX one or the FP one) to use to update the
> debuggee's registers.  

No, as I envision things, GDB would only write the "real"
registers back to the target.  The "pseudo-registers" would
be like internal variables -- computed, not fetched or stored.
There would be only one (ten byte) storage location in GDB
shared by the FP register and the MMX register.  The difference
between the two would be only the name and possibly how the 
data was interpreted.

> To complicate things even more, a separate
> change by the user of some control register might mean that the FPU
> should be switched into or out of the MMX mode, which changes the way
> values in the aliased registers are interpreted.

Well, you're over my head now.  I don't know anything about
Pentium processor states.

> To make the long story short: to support MMX registers as an alias for
> the FP registers, GDB needs additional information from the
> target-specific code.  I didn't really think too much about this, but
> the following aspects might be useful for the GDB application level:
> 
>   - what is the current association between MMX[i] and FP[j] register,
>     that is, which MMX register is an alias for a given FP register--
>     this is required to update all of the aliases of a given physical
>     register;

You should talk to Fernando Nasser, who knows way more about
Pentium and its coprocessors than I do.  Fernando?  How would 
you approach this (hypothetically)?

>   - what is the current FPU mode (MMX or FP)--if we know this, we
>     might elect to refuse an update of the MMX registers if the FPU is
>     not in MMX mode, or at least print a warning.
> 
> Given this, and possibly some more, info, GDB should exercise some
> non-trivial logic at resume time, to put correct values and in correct
> order into the debuggee's registers.  Alternatively, GDB's application
> level should pass enough information to the target-specific code for
> it to make those decisions; in particular, the target might need to
> know the chronological order in which the user changed registers'
> values.
> 
> This is a far cry from the current code that simply walks the register
> file in its fixed order and passes the value of each register to the
> target for storage one by one.
> 
> Of course, this all might mean that the MMX issue is not really suited
> for the kind of solution you have in mind ;-).