From ebc76ef6e6017b3548207c45abf33ab6e8f9402d Mon Sep 17 00:00:00 2001 From: Simon Marchi Date: Thu, 7 Sep 2023 22:26:59 -0400 Subject: [PATCH] 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 --- gdb/testsuite/gdb.arch/amd64-init-x87-values.exp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/testsuite/gdb.arch/amd64-init-x87-values.exp b/gdb/testsuite/gdb.arch/amd64-init-x87-values.exp index eb0e35ff7f7..0738fc4e474 100644 --- a/gdb/testsuite/gdb.arch/amd64-init-x87-values.exp +++ b/gdb/testsuite/gdb.arch/amd64-init-x87-values.exp @@ -99,7 +99,7 @@ proc_with_prefix check_x87_regs_around_init {} { "fstat" "0x3800" \ "ftag" "0x3fff" \ "fiseg" "0x0" \ - "fioff" $addr \ + "fioff" "($addr|0x0)" \ "foseg" "0x0" \ "fooff" "0x0" \ "fop" "0x0" \ -- 2.30.2