aboutsummaryrefslogtreecommitdiff
path: root/gdb
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2022-12-12 14:25:58 +0100
committerTom de Vries <tdevries@suse.de>2022-12-12 14:25:58 +0100
commit167f3beb655da160e9241e76b7f8b1855b30c903 (patch)
treea3bf298f03a1b6dc47f5edb837ebe1939f6deb6d /gdb
parentb5661ff24f7111246b9e9b5f1cba5afe9d479daf (diff)
downloadbinutils-167f3beb655da160e9241e76b7f8b1855b30c903.zip
binutils-167f3beb655da160e9241e76b7f8b1855b30c903.tar.gz
binutils-167f3beb655da160e9241e76b7f8b1855b30c903.tar.bz2
[gdb/testsuite] Fix gdb.base/write_mem.exp for big endian
On s390x-linux (big endian), I run into: ... (gdb) x /xh main^M 0x1000638 <main>: 0x0000^M (gdb) FAIL: gdb.base/write_mem.exp: x /xh main ... In contrast, on x86_64-linux (little endian), we have the expected: ... (gdb) x /xh main^M 0x4004a7 <main>: 0x4242^M (gdb) PASS: gdb.base/write_mem.exp: x /xh main ... The problem is that the test-case hard-codes expectations about endiannes by writing an int-sized value (4 bytes in this case) and then printing only a halfword by using "/h" (so, two bytes). If we print 4 bytes, we have for s390x: ... 0x1000638 <main>: 0x00004242^M ... and for x86_64: ... 0x4004a7 <main>: 0x00004242^M ... Fix this by removing the "/h". Tested on x86_64-linux and s390x-linux.
Diffstat (limited to 'gdb')
-rw-r--r--gdb/testsuite/gdb.base/write_mem.exp2
1 files changed, 1 insertions, 1 deletions
diff --git a/gdb/testsuite/gdb.base/write_mem.exp b/gdb/testsuite/gdb.base/write_mem.exp
index a9e9403..ce862a5 100644
--- a/gdb/testsuite/gdb.base/write_mem.exp
+++ b/gdb/testsuite/gdb.base/write_mem.exp
@@ -42,6 +42,6 @@ gdb_test_no_output "set {int}main = 0x4242"
# Check that memory write persists after quitting GDB
gdb_exit
gdb_start
-gdb_test "x /xh main" "<main>:.*4242"
+gdb_test "x /x main" "<main>:.*4242"
set GDBFLAGS $old_gdbflags