Re: WIP: Register doco

[Andrew Cagney <ac131313@ges.redhat.com>]

> The example of the IA-32's MMX and FP registers is a great example for
> this.  The MMX registers, MM0--MM7, and the FP registers,
> ST(0)--ST(7), actually refer to the same set of eight eighty-bit
> registers, R0--R7.  A reference to the floating-point register ST(i)
> becomes a reference to R((TOP + i) % 8), where TOP is a three-bit
> field in the FPU status register.  But a reference to the MMX register
> MM(i) becomes a reference to the lower 64 bits of R(i) (which would be
> the mantissa of some ST(i)).

(In the current code, ST(I) and not R(I) is stored, so we end up with 
MM(I) == regcache(FP0 + (TOP + 1) % 8) :-(   I'm almost ready to dust 
off the patch that does this.)

Anyway, I think the above example highlights why I see it as important 
to use terms like ``hardware'' or even ``physical''.  Those terms drag 
the GDB developer's eye away from those glossy user level ISA specs, and 
instead focuses their attention on the underlying hardware model used to 
implement the userland ISA. While well above the level of flip-flops, it 
is still a clear step below the ISA that a typical native GDB user will 
be aware of.  (A PPC refers to the ``operating environment architecture'').

For the i387, the programmer spec is all about a register stack, yet the 
underlying hardware uses a block of 8 registers and an index.  It is the 
latter, the lower level hardware details, that the GDB developer should 
focus their attention on when deciding the contents of a register cache.

> processors, then there are all sorts of confusing questions that
> brings up --- e.g., "How in the world would GDB get hold of the state
> of the raw flip-flops on a native Linux system?")

Clearly that isn't low level enough!  GDB needs to be getting down to 
the level of quantum effects :-^

There is a bit of irony here mind.  The i386 Linux kernel correctly 
provides a low-level hardware view of the i387 registers (the 8 register 
block and the index).   Current GDB however, by failing to abstract the 
raw register cache at that same low level, has ended up suffering from a 
series of obscure FP vs THREAD related register corruption bugs.

enjoy,
Andrew