[Bug tdep/21865] New: MMX registers are presented in wrong order when FSW.TOP!=0

["b7.10110111 at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21865

            Bug ID: 21865
           Summary: MMX registers are presented in wrong order when
                    FSW.TOP!=0
           Product: gdb
           Version: 8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: tdep
          Assignee: unassigned at sourceware dot org
          Reporter: b7.10110111 at gmail dot com
  Target Milestone: ---

Consider the following x86 assembly program (compiled by FASM):

format ELF executable
    fldpi
    fldl2t
    fldl2e
    fldln2
    fldlg2

    int3

    movd eax, mm0
    movd ecx, mm1
    movd edx, mm2
    movd ebx, mm3

    xor ebx, ebx
    mov eax, 1
    int 0x80

Running it with
gdb -q ./test -ex r -ex 'p/x
{$mm0.v2_int32[0],$mm1.v2_int32[0],$mm2.v2_int32[0],$mm3.v2_int32[0]}' -ex 'si
4' -ex 'p/x {$eax,$ecx,$edx,$ebx}' -ex 'p/x
{$mm0.v2_int32[0],$mm1.v2_int32[0],$mm2.v2_int32[0],$mm3.v2_int32[0]}'

gives us:

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0804805f in ?? ()
$1 = {0xcd1b8afe, 0x2168c235, 0x0, 0x0}
0x0804806b in ?? ()
$2 = {0x0, 0x0, 0x0, 0xfbcff799}
$3 = {0x0, 0x0, 0x0, 0xfbcff799}

The $1 result is wrong, since MMn registers are actually mapped to Rn FPU
registers, while GDB seems to somehow think of the mapping being dependent on
STn or something. If I set $fstat=0 (so that TOP=0), then the order of MMn
register values on subsequent printing is correct.

The result $3 is right, but it is only due to the access to MM0 by MOVD
instruction, which clears TOP field in $fstat.

-- 
You are receiving this mail because:
You are on the CC list for the bug.