Re: none

[Jim Blandy <jimb at cygnus dot com>]

> Here are my $0.02 on this:
> 
> > - Assign them register numbers separate from the FP stack registers'.
> > - Assign them the same numbers as the FP stack registers, and treat them as
> >   an alternative way of looking at the FP registers' mantissas.
> > The first approach has some problems
> 
> Right.  If we do NOT treat the FP and MMX registers as the same
> registers, we are in for a lot of trouble.  the only sane way is to
> treat them as different views of the same register set.
> 
> > The problem is, we're using the same register number for %mm0 and
> > %st(0), but %mm0 doesn't really correspond to %st(0).  It depends on
> > the value of the FPU TOS register.
> 
> Yes, this is not right.  $mm0 should correspond to R0, not to $st0.
> However, I don't think it is wise to rely on the program's code to
> play by the rules (which effectively guarantee that $mm0 corresponds
> to $st0).  Some clever programmer out there is bound to produce code
> that uses FP instructions on data left from MMX instructions without
> issuing EMMS in between.  GDB should not be confused by such code.
> 
> But why is this a problem?  Can't we make the correspondence be
> dynamically computed at run time, using the current TOS?  If not, why
> not?

When the compiler allocates a variable to the MMX register MM0, it
needs to use some number in the debug info to represent MM0.  If it
allocates a variable to the FP register ST(0), it needs to use some
number.

The compiler cannot assign numbers to the absolute FP registers R0,
R1, etc. because the compiler has no idea where TOS is upon function
entry.  Whatever numbering it uses has to be TOS-dependent in some
way.

So, does the compiler use separate numbers in the debug for MMX
registers and FP stack registers, or the same numbers?

If the compiler uses separate register numbers, then we have the
problems discussed before: as far as I can tell, GDB simply isn't set
up to cope with the idea that certain bits might be part of two
registers.

If the compiler uses the same register numbers, how can the
architecture-specific code tell whether GDB is accessing MM0 (which
lives in R0) or ST(0) (which lives in R(TOS))?

Do you see the problem here?

One principle I want any solution to follow is: don't mess with the
generic part of GDB.  This is stupid ugly hair from an architecture
pushed beyond its proper limits, with crushing backward compatibility
requirements.  It's an x86 problem, and it should be addressed in
x86-specific code.

Given that restriction, I'm not sure we can do any better than the
solution I've described.  I'd love to hear suggestions.