Feature request: FPU and XMM registers

[Indrekis]

Is it possible/(simple enough) to add means for inspecting FPU, XMM, MMX (and so on?) registers to debugging facility?

[thomas]

Naively speaking, this is as easy as replacing "info registers" with "info all-registers" in gdb_commands.h, line 910. Alternatively, the xmm registers can be read out (like all others) using print $xmmnumber.

However, the parser would have to be modified to interprete the additional information, too. Thus, it is a little more complicated, in particular when it comes to xmm registers, as their value is not unambiguously defined.
Any of the "vector" registers may hold a varying number of integers of varying width or floating point and double values. Register xmm1 may hold four float values while xmm2 holds integers, and you have no way to tell which is which. To make matters worse, the register set and what can be in which register also depends on your CPU (MMX/SSE/SSE2/SSE3).
It is not entirely trivial to write a parser and to offer a good visual representation for all this. The debugger solves the ambiguity problem by outputting a register in several representations (7 in total, if I am not mistaken).

<edit>Forgot to mention another problem: Since the MMX registers and the floating point registers are indeed the the same physical set of registers, you have yet another thing which you have to guess to display it right.</edit>

Do you have an idea on how to display the contents of the xmm registers in a better way?

For the time being, you can still issue that command manually and look at the debugger's output log.

[Game_Ender]

About the debugger commands, is there a better way than hitting the menu option, and just typing in there?  That is very incovient if you to issue the command over and over.

In Xcode (which also wraps GBD) they give the option of opening up a console to the debugger, it would be cool if you could do the same in codeblocks.  Perhaps changing the debugger messages window, to a debugger console.

[Indrekis]

Do you have an idea on how to display the contents of the xmm registers in a better way?

Meaning of content of XMM registers is not fixed. In other words, citing "IA-32 Intel Architecture Software Developer's Manual; Volume 1, Basic Architecture", section 11.6.9:

SSE and SSE2 extensions define typed operations on packed and scalar floating-point data types
and on 128-bit SIMD integer data types, but IA-32 processors do not enforce this typing at the
architectural level. They only enforce it at the microarchitectural level. Therefore, when a
Pentium 4 or Intel Xeon processor loads a packed or scalar floating-point operand or a 128-bit
packed integer operand from memory into an XMM register, it does not check that the actual
data being loaded matches the data type specified in the instruction. Likewise, when the
processor performs an arithmetic operation on the data in an XMM register, it does not check
that the data being operated on matches the data type specified in the instruction.

As a general rule, because data typing of SIMD floating-point and integer data types is not
enforced at the architectural level, it is the responsibility of the programmer, assembler, or
compiler to insure that code enforces data typing.

(italisized by me)

Moreover, mixing different interpretations of data in XMM register is directly allowed (for some cases) in the manual:

The ability to operate on an operand that contains a data type that is inconsistent with the typing
of the instruction being executed, permits some valid operations to be performed. For example,
the following instructions load a packed double-precision floating-point operand from memory
to register XMM0, and a mask to register XMM1; then they use XORPD to toggle the sign bits
of the two packed values in register XMM0.

movapdxmm0, [eax] ; EAX register contains pointer to packed
                               ; double-precision floating-point operand
movapsxmm1, [ebx] ; EBX register contains pointer to packed
                               ; double-precision floating-point mask
xorpdxmm0, xmm1   ; XOR operation toggles sign bits using
                               ; the mask in xmm1

As a result, IMHO, it is better let user choose, how to interprete content of XMM registers in per-register basis. (Example - implementation of viewing XMM(x) in the Insight debugger.)


Note about data types:

SSE introduces one data type: 128-bit packed single-precision floating-point data type.
SSE2 introduces 5 new types:

• Packed double-precision floating-point
• 128-bit packed byte integers
• 128-bit packed word integers
• 128-bit packed doubleword integers
• 128-bit packed quadword integers

SSE3 does not introduce new data types.

Displaying MXCSR control/status register will be useful too 

To make matters worse, the register set and what can be in which register also depends on your CPU (MMX/SSE/SSE2/SSE3).

Is gdb showing contents of not present in current CPU registers??
(It do shows "Packed double-precision floating-point" ans so on interpretations in processor without SSE2)

<edit>Forgot to mention another problem: Since the MMX registers and the floating point registers are indeed the the same physical set of registers, you have yet another thing which you have to guess to display it right.</edit>

For FPU/MMX pair situation is little bit different. It looks like some heuristic analysis can be done here. According to the manual:

When an MMX instruction (other than the EMMS instruction) is executed, the processor
changes the x87 FPU state as follows:

• The TOS (top of stack) value of the x87 FPU status word is set to 0.
• The entire x87 FPU tag word is set to the valid state (00B in all tag fields).
• When an MMX instruction writes to an MMX register, it writes ones (11B) to the exponent part of the corresponding floating-point register (bits 64 through 79).

But it can be complicated enough and not necessary. IMHO, here approach, mentioned before for the XMM is the best too. Generally speaking, almost every program starts, assuming that FPU contains no data, so treating FPU registers as  FPU registers (not MMX registers) is reasonable default.

Of cause, there can be two global user-selectable displaying modes - FPU and MMX; and MMX having "submodes", individual for each register ("Packed byte, packed word, packed doubleword")

What do you think about such a model?

[Indrekis]

In Xcode (which also wraps GBD) they give the option of opening up a console to the debugger, it would be cool if you could do the same in codeblocks.  Perhaps changing the debugger messages window, to a debugger console.

I miss this feature too 

[brunov21]

Hi

I miss this feature too 

What is this gdb_commands.h and this line 910 ? I cannot find it on my xubuntu distro for amd64.
Is there any way to plugin ?
Just getting the register window with hexa value of any MMX/XMM register would be so fine for me ! (click menu +...+ "print xmmNN" is tedious)

(an inline assembler with *no* AT&T syntax would be of great value too).

Nice work anyway, guys !
Bye

[Indrekis]

gdb_commands.h is a part of CB sources, and in my local copy of sources resist at:
<CB_SVN_COPY>\trunk\src\plugins\debuggergdb\gdb_commands.h

As for the CB, assembler flavour can be changed in Settings -> Compiler and Debugger settings -> Debugger settings -> Choose disassembly flavour (GDB only)

For the gcc compiler, Intel flavour for all following inline asm can be turned on by the statement:
asm(".intel_syntax noprefix\n");
To complie files with such "instruction" one should use -masm=intel option.

For example,
main.cpp:

int main (void)
{
asm(".intel_syntax noprefix\n");
asm("mov edx,5\n");
}

can be compiled by:

gcc -masm=intel main.cpp -o intel_asm_sample

In CB one may set this option in Project -> build options... -> Compiler settings -> Other options -> here add the line "-masm=intel" .
 

[brunov21]

 :shock: Great ! Both work, console and CB 

(no need for '\n')
  asm(".intel_syntax noprefix");
  asm("mov edx,5");
  asm("psadbw xmm0,xmm15");
  asm("pavgb xmm0,xmm8");

Many thanks 

[sad]
however there is a drawback: the code below is *not* valid with the option -masm=intel 
unsigned long long foo=0;
int main (void)
{
foo=0x123456789abcdef;
...

I'll have to search through gcc 4.1.3 options
[/sad]

[Indrekis]

You are welcome 

'\n' was necessary for me. Without it next asm statement (either my own or generated by compiler) appears at the same line, leading to errors in the assembly stage. Though that '\n' was annoying.
(It was under gcc-MinGW-3.4.4)

[haduken]

If when the processor performs an arithmetic operation on the data in an XMM register maybe i could not use as the feature request.


_________________
Stereolithography

[XayC]

I'm trying to add this feature to the debugger plug-in. The two screenshots show the results so far.
The first one shows the standard registers and floating point registers, the second screenshot shows the multimedia registers.

Changes:
- As thomas suggested register status is now taken using info all-registers command.
- The results from GDB are now parsed inside the CPURegistersDlg class.
- Changed the way data is updated in the registers dialog. Now every time an update is performed, all the elements in the dialog are removed and re-added. While this is simpler and cleaner, every update cancels the current selection and view in the dialog.

Problems or things still to-do:
- Support the parsing of OR32 style too (look at plugins\debuggergdb\gdb_commands.h function ParseOutputFromOR32gdbPort).
- Support the parsing of CDB output.
- Highlighting of changed registers.
- Better parsing of the multimedia registers value. Currently the GDB output is split using the "}," separator, which works and it's easy, but doesn't give the best results.

XayC

[attachment deleted by admin]

[MortenMacFly]

I'm trying to add this feature to the debugger plug-in.

Nice work so far!

[XayC]

The feature (show FPU, MMX and XMM registers) is complete.
The first screenshot shows the new registers dialog docked, showing only the basic registers. The second screenshot shows the dialog, floating, showing all the registers.
The check box in the dialog is used to switch between the two modes.

The following files have been changed. The code to parse the output from the debugger has been moved from cdb_commands.h / gdb_commands.h to the dialog class.

Code

src/plugins/debuggergdb/cpuregistersdlg.cpp
src/plugins/debuggergdb/cpuregistersdlg.h
src/plugins/debuggergdb/cdb_commands.h
src/plugins/debuggergdb/gdb_commands.h

Changes / new features:
- Using a check box it's possible to show only basic registers or all registers (only supported with x86 GDB).
- Flag registers will now show also the single flags names (in addition to the hexadecimal value).
- Kept the support for OR32 architecture and CDB debugger.

This patch should close the following feature requests: 4108 (Registers window improvement), 2754 (Support for FPU and XMM registers).

This patch has not been tested with GDB OR30 architecture and with CDB.

XayC


[attachment deleted by admin]

[oBFusCATed]

Good work,
But why don't you use a property grid(propgrid) control?
With it I think you can have a tree like structure and save a bit of space.

Another option is to add a third column in the current  control,
which will be used to display the type of data displayed in the second column.
The type of the register could be controlled by a context menu, active only for the XMM registers.
And when the users sets the type of the register it is remembered for the next refreshes, runs of the debugger.

Best regards...