Re: [RFC]: Pseudo-registers for GDB

[Eli Zaretskii <eliz at delorie dot com>]

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

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.

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

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;

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