[Bug testsuite/28504] New: FAIL: gdb.arch/i386-sse.exp: check contents of data[2]

[Bug testsuite/28504] New: FAIL: gdb.arch/i386-sse.exp: check contents of data[2]

[vries at gcc dot gnu.org]

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

            Bug ID: 28504
           Summary: FAIL: gdb.arch/i386-sse.exp: check contents of data[2]
           Product: gdb
           Version: 11.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: testsuite
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

FTR, I ran into a cluster of failures on OBS (only showing one FAIL per
test-case), all on the same machine:
...
binaries-testsuite.openSUSE_Factory.x86_64/gdb-testresults/gdb-x86_64-suse-linux-m64.-fno-PIE.-no-pie.sum:
FAILs:
FAIL: gdb.arch/i386-sse.exp: check contents of data[2]
FAIL: gdb.base/call-ar-st.exp: print print_small_structs (timeout)
FAIL: gdb.base/callfuncs.exp: call function with many float arguments.
FAIL: gdb.base/dfp-test.exp: backtrace function with correct _Decimal32
arguments.
FAIL: gdb.base/varargs.exp: print find_max_float_real(4, fc1, fc2, fc3, fc4)
FAIL: gdb.reverse/i386-sse-reverse.exp: verify xmm2 after reverse xorps

binaries-testsuite.openSUSE_Factory.x86_64/gdb-testresults/gdb-x86_64-suse-linux-m64.sum:
FAILs:
FAIL: gdb.arch/i386-sse.exp: check contents of data[2]
FAIL: gdb.base/call-ar-st.exp: print print_small_structs (timeout)
FAIL: gdb.base/callfuncs.exp: call function with many float arguments.
FAIL: gdb.base/dfp-test.exp: backtrace function with correct _Decimal32
arguments.
FAIL: gdb.base/varargs.exp: print find_max_float_real(4, fc1, fc2, fc3, fc4)
FAIL: gdb.reverse/i386-sse-reverse.exp: verify xmm2 after reverse xorps

binaries-testsuite.openSUSE_Factory.x86_64/gdb-testresults/gdb-x86_64-suse-linux-m32.-fno-PIE.-no-pie.sum:
FAILs:
FAIL: gdb.arch/i386-sse.exp: check contents of data[2]
FAIL: gdb.reverse/i386-sse-reverse.exp: verify xmm2 after reverse xorps
...

The first FAIL looks like:
...
(gdb) PASS: gdb.arch/i386-sse.exp: check contents of data[1]
print data[2]^M
$36 = {f = {0, 0, 0, 0}}^M
(gdb) FAIL: gdb.arch/i386-sse.exp: check contents of data[2]
...

The FAILs extends over 8 elements (elements 2-9):
...
PASS: gdb.arch/i386-sse.exp: check contents of data[1]
FAIL: gdb.arch/i386-sse.exp: check contents of data[2]
FAIL: gdb.arch/i386-sse.exp: check contents of data[3]
FAIL: gdb.arch/i386-sse.exp: check contents of data[4]
FAIL: gdb.arch/i386-sse.exp: check contents of data[5]
FAIL: gdb.arch/i386-sse.exp: check contents of data[6]
FAIL: gdb.arch/i386-sse.exp: check contents of data[7]
FAIL: gdb.arch/i386-sse.exp: check contents of data[8]
FAIL: gdb.arch/i386-sse.exp: check contents of data[9]
PASS: gdb.arch/i386-sse.exp: check contents of data[10]
...

I wonder if this is a dcache bug of some sort.

Dcache line size is 64 bytes.

The data array has 16 elements, of size 16 each:
...
(gdb) p sizeof(data[0])
$3 = 16
...

4 elements fit into a dcache line.  The failure stretches over the size of two
dcache lines.

OTOH, looking at:
...
(gdb) PASS: gdb.reverse/i386-sse-reverse.exp: verify xmm1 after reverse xorps
info register xmm2^M
xmm2           {v8_bfloat16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
v4_float = {0x0, 0x0,\
 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>},
v8_int16 = {0x0, 0x0\
, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 =
{0x0, 0x0}, uint\
128 = 0x0}^M
(gdb) FAIL: gdb.reverse/i386-sse-reverse.exp: verify xmm2 after reverse xorps
...
the problem is related to xmm2, and in the previous test-case the data[2]
element is copied from xmm2.  So perhaps it's register-related?

Anyway, we could extend the gdb.arch/i386-sse.exp test-case to print the
registers after the update, before they're written back to data, to possibly
narrow down this problem in the future.

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

[Bug testsuite/28504] FAIL: gdb.arch/i386-sse.exp: check contents of data[2]

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> Anyway, we could extend the gdb.arch/i386-sse.exp test-case to print the
> registers after the update, before they're written back to data, to possibly
> narrow down this problem in the future.

https://sourceware.org/pipermail/gdb-patches/2021-October/182857.html

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

[Bug testsuite/28504] FAIL: gdb.arch/i386-sse.exp: check contents of data[2]

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Running
/home/abuild/rpmbuild/BUILD/gdb-11.1/gdb/testsuite/gdb.testsuite/dump-system-info.exp
...
Executing on target: cat /proc/cpuinfo    (timeout = 300)
builtin_spawn -ignore SIGHUP cat /proc/cpuinfo^M
processor       : 0^M
vendor_id       : GenuineIntel^M
cpu family      : 6^M
model           : 26^M
model name      : Intel(R) Xeon(R) CPU           E5506  @ 2.13GHz^M
stepping        : 5^M
microcode       : 0x11^M
cpu MHz         : 2133.245^M
cache size      : 16384 KB^M
physical id     : 0^M
siblings        : 1^M
core id         : 0^M
cpu cores       : 1^M
apicid          : 0^M
initial apicid  : 0^M
fpu             : yes^M
fpu_exception   : yes^M
cpuid level     : 11^M
wp              : yes^M
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc
arch_perfmon rep_good nopl xtopology cpuid pni vmx ssse3 cx16 sse4_1 sse4_2
x2apic popcnt tsc_deadline_timer hypervisor lahf_lm cpuid_fault tpr_shadow vnmi
flexpriority ept vpid tsc_adjust arat umip arch_capabilities^M
vmx flags       : vnmi preemption_timer invvpid ept_x_only ept_1gb flexpriority
tsc_offset vtpr mtf vapic ept vpid shadow_vmcs^M
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds
swapgs^M
bogomips        : 4266.49^M
clflush size    : 64^M
cache_alignment : 64^M
address sizes   : 40 bits physical, 48 bits virtual^M
power management:^M
...

FTR, also:
...
Linux cloud109 5.14.14-3-default #1 SMP Thu Oct 21 05:05:03 UTC 2021 (2b5383f)
x86_64 x86_64 x86_64 GNU/Linux^M
...

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

[Bug testsuite/28504] FAIL: gdb.arch/i386-sse.exp: check contents of data[2]

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
Hit this again, on a different machine:
...
Linux cloud113 5.15.2-1-default #1 SMP Sat Nov 13 14:10:12 UTC 2021 (26a203b)
x86_64 x86_64 x86_64 GNU/Linux^M
...

Same cpu though:
...
model name      : Intel(R) Xeon(R) CPU           E5506  @ 2.13GHz^M
...

I've also added an extra check, after the register set to verify the register
contents.  I've also enabled some debug prints, so we got:
...
(gdb) PASS: gdb.arch/i386-sse.exp: check float contents of %xmm1 after add
set var $xmm2.v4_float[0] = 2 + 10^M
-> multi-thread->log_command (...)^M
<- multi-thread->log_command (set var $xmm2.v4_float[0] = 2 + 10)^M
-> multi-thread->thread_address_space (...)^M
<- multi-thread->thread_address_space (23546) = 1^M
-> multi-thread->thread_address_space (...)^M
<- multi-thread->thread_address_space (23546) = 1^M
-> multi-thread->prepare_to_store (...)^M
<- multi-thread->prepare_to_store (0x55fb8deb8ae0)^M
-> multi-thread->store_registers (...)^M
<- multi-thread->store_registers (0x55fb8deb8ae0, 42)^M
target_store_registers (xmm2) = 00004041000000000000000000000000^M
-> multi-thread->thread_architecture (...)^M
<- multi-thread->thread_architecture (23546) = i386:x86-64^M
-> multi-thread->thread_address_space (...)^M
<- multi-thread->thread_address_space (23546) = 1^M
-> multi-thread->get_unwinder (...)^M
<- multi-thread->get_unwinder () = 0x0^M
-> multi-thread->get_tailcall_unwinder (...)^M
<- multi-thread->get_tailcall_unwinder () = 0x0^M
-> multi-thread->thread_address_space (...)^M
<- multi-thread->thread_address_space (23546) = 1^M
-> multi-thread->fetch_registers (...)^M
<- multi-thread->fetch_registers (0x55fb8deb8ae0, 16)^M
target_fetch_registers (rip) = 5316400000000000 0x401653 4200019^M
multi-thread:target_xfer_partial (3, (null), 0x55fb8e0cfc80, 0x0,
0x7fffffffd6e8, 8) = 1, 8, bytes =^M
 c0 d5 dc f7 ff 7f 00 00^M
(gdb) PASS: gdb.arch/i386-sse.exp: set %xmm2
print $xmm2.v4_float^M
-> multi-thread->log_command (...)^M
<- multi-thread->log_command (print $xmm2.v4_float)^M
-> multi-thread->thread_address_space (...)^M
<- multi-thread->thread_address_space (23546) = 1^M
-> multi-thread->fetch_registers (...)^M
<- multi-thread->fetch_registers (0x55fb8deb8ae0, 42)^M
target_fetch_registers (xmm2) = 00000000000000000000000000000000^M
-> multi-thread->supports_memory_tagging (...)^M
<- multi-thread->supports_memory_tagging () = false^M
$36 = {0, 0, 0, 0}^M
(gdb) FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm2 after add
...

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