gdb/testsuite: fix gdb.arch/amd64-init-x87-values.exp on AMD CPUs

gdb/testsuite: fix gdb.arch/amd64-init-x87-values.exp on AMD CPUs

I see the following failure when running this test on an AMD machine:

    p/x $fioff^M
    $24 = 0x0^M
    (gdb) FAIL: gdb.arch/amd64-init-x87-values.exp: check_x87_regs_around_init: check post FLD1 value of $fioff

The register that GDB calls fioff normally contains the address of the
last instruction executed by the x87 unit.  It is available through the
FSAVE/FXSAVE/XSAVE instructions, at offset 0x8 of the FSAVE/FXSAVE/XSAVE
area.  You can read about it in the Intel manual [1] at section "10.5.1
FXSAVE Area" (and equivalent sections for FSAVE and XSAVE) or in the AMD
manual [2] at section "11.4.4 Saving Media and x87 Execution Unit
State".

The test therefore expects that after executing the FLD1 instruction,
the fioff register contains the address of the FLD1 instruction.

However, the FXSAVE and XSAVE instructions (which the kernel uses to
dump x87 register state which it provides GDB through ptrace) behave
differently on AMD CPUs.  In section "11.4.4.3 FXSAVE and FXRSTOR
Instructions" of the AMD manual, we read:

    The FXSAVE and FXRSTOR instructions save and restore the entire
    128-bit media, 64-bit media, and x87 state. These instructions
    usually execute faster than FSAVE/FNSAVE and FRSTOR because they do
    not normally save and restore the x87 exception pointers
    (last-instruction pointer, last data-operand pointer, and last
    opcode). The only case in which they do save the exception pointers
    is the relatively rare case in which the exception-summary bit in
    the x87 status word (FSW.ES) is set to 1, indicating that an
    unmasked exception has occurred.

So, unless a floating point exception happened and that exception is
unmasked in the x87 FPU control register (which isn't by default on
Linux, from what I saw), the "last instruction address" register (or
fioff as GDB calls it) will always be 0 on an AMD CPU.

For this reason, I think it's fine to change the test to accept the
value 0 - that's just how the processor works.

I toyed with the idea of changing the test program to make it so the CPU
would generate a non-zero fioff.  That is by unmasking an FPU exception
and executing an instruction to raise that kind exception.  It worked,
but then I would have to change the test more extensively, and it didn't
seem to be worth it.

[1] https://cdrdv2.intel.com/v1/dl/getContent/671200
[2] https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf

Change-Id: If2e1d932f600ca01b15f30b14b8d38bf08a3e00b
Reviewed-by: John Baldwin <jhb@FreeBSD.org>