aboutsummaryrefslogtreecommitdiff
path: root/ld/pdb.h
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2024-06-19 10:04:22 +0200
committerTom de Vries <tdevries@suse.de>2024-06-19 10:04:22 +0200
commit81ad8a2444b85fe1ea4515285f8bd569363cac12 (patch)
treeb566b1f81ee2a81a2374d222b0aed070081f2c21 /ld/pdb.h
parent78564d3f6c131db76a01de9492690a812e5e9141 (diff)
downloadgdb-81ad8a2444b85fe1ea4515285f8bd569363cac12.zip
gdb-81ad8a2444b85fe1ea4515285f8bd569363cac12.tar.gz
gdb-81ad8a2444b85fe1ea4515285f8bd569363cac12.tar.bz2
[gdb/testsuite] Fix gdb.dwarf2/shortpiece.exp on s390x
On s390x-linux, I run into: ... (gdb) p (short []) s1^M $3 = {0, 1, 0, <optimized out>}^M (gdb) FAIL: gdb.dwarf2/shortpiece.exp: p (short []) s1 ... while this is expected: ... (gdb) p (short []) s1^M $3 = {1, 0, 0, <optimized out>}^M (gdb) PASS: gdb.dwarf2/shortpiece.exp: p (short []) s1 ... The type of s1 is: ... (gdb) ptype s1 type = struct S { myint a; myushort b; } ... so the difference is due the fact that viewing an int as two shorts gives different results depending on the endianness. Fix this by allowing both results. Tested on x86_64-linux and s390x-linux. Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'ld/pdb.h')
0 files changed, 0 insertions, 0 deletions