diff options
author | Tom de Vries <tdevries@suse.de> | 2024-06-19 10:04:22 +0200 |
---|---|---|
committer | Tom de Vries <tdevries@suse.de> | 2024-06-19 10:04:22 +0200 |
commit | 81ad8a2444b85fe1ea4515285f8bd569363cac12 (patch) | |
tree | b566b1f81ee2a81a2374d222b0aed070081f2c21 /gdb/valops.c | |
parent | 78564d3f6c131db76a01de9492690a812e5e9141 (diff) | |
download | binutils-81ad8a2444b85fe1ea4515285f8bd569363cac12.zip binutils-81ad8a2444b85fe1ea4515285f8bd569363cac12.tar.gz binutils-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 'gdb/valops.c')
0 files changed, 0 insertions, 0 deletions