https://bugzilla.suse.com/show_bug.cgi?id=1179538 https://bugzilla.suse.com/show_bug.cgi?id=1179538#c2 --- Comment #2 from Tom de Vries <tdevries@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.