Comment # 2 on bug 1179538 from Tom de Vries

(In reply to Borislav Petkov from comment #1)
> Hmmm, strange.
> 
> Looking at that test in gdb, it does only this, right?
> 
>     gdb_test_no_output "set \$mxcsr=0x9f80" "set a new value for MXCSR"
>     gdb_test "stepi" "fwait" "step forward one instruction for mxcsr test"
> 
> so basically I should be able to reproduce this in a VM, right?

I don't understand yet the precise conditions under which this triggers.

> Do I need some special version of gdb or it doesn't matter?
> 

This is with the gdb currently in devel:gcc, it might also reproduce with
others.

> Also, can you dump the new MXCSR value in the test so that we can see what
> it sets it to?
> 

Added a print after the set in command below.

To reproduce on command line (this is a session on openSUSE Leap 15.2 with
kernel version 5.3.18, so $3 is as expected):
...
$ gcc -fno-stack-protector -static -nostartfiles -g \
    src/gdb/testsuite/gdb.arch/amd64-init-x87-values.S
$ gdb -batch a.out \
    -ex start \
    -ex "p /x \$mxcsr = 0x9f80" \
    -ex "p /x \$mxcsr" \
    -ex stepi \
    -ex "p /x \$mxcsr"
Temporary breakpoint 1 at 0x4000d5: file
src/gdb/testsuite/gdb.arch/amd64-init-x87-values.S, line 27.

Temporary breakpoint 1, main () at
src/gdb/testsuite/gdb.arch/amd64-init-x87-values.S:27
27              nop
$1 = 0x9f80
$2 = 0x9f80
28              fwait
$3 = 0x9f80
...

> Also, you're running this on baremetal, right, not in a VM?

It's from an obs log, so kvm. I haven't been able to reproduce this outside
yet.