aboutsummaryrefslogtreecommitdiff
path: root/gdb/aarch64-tdep.c
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2023-01-19 13:44:13 +0100
committerTom de Vries <tdevries@suse.de>2023-01-19 13:44:13 +0100
commita0d5ef869da20e023e4b75860012c56273f26d92 (patch)
tree10bff0c68efad75a4c6d98f558942615452adf8b /gdb/aarch64-tdep.c
parent75c2efc6f19fe454413aa70d2c37e543f04a67e1 (diff)
downloadbinutils-a0d5ef869da20e023e4b75860012c56273f26d92.zip
binutils-a0d5ef869da20e023e4b75860012c56273f26d92.tar.gz
binutils-a0d5ef869da20e023e4b75860012c56273f26d92.tar.bz2
[gdb/testsuite] Fix gdb.python/py-value-cc.exp for big endian
On s390x-linux, I run into: ... (gdb) python print(u[u_fields[0]])^M 99^M (gdb) PASS: gdb.python/py-value-cc.exp: u's first field via field python print(u[u_fields[1]])^M 0 '\000'^M (gdb) FAIL: gdb.python/py-value-cc.exp: u's second field via field ... There's a var u of this type: ... union U { int a; char c; }; ... and after assigning 99 to u.a, the test-case expects u.c to contain 99 (which it does on x86_64), but instead it contains 0. Fix this by instead assigning 0x63636363, to ensure that u.c == 99 for both little and big endian. Tested on x86_64-linux and s390x-linux.
Diffstat (limited to 'gdb/aarch64-tdep.c')
0 files changed, 0 insertions, 0 deletions