From 167f3beb655da160e9241e76b7f8b1855b30c903 Mon Sep 17 00:00:00 2001 From: Tom de Vries Date: Mon, 12 Dec 2022 14:25:58 +0100 Subject: [PATCH] [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
: 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
: 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
: 0x00004242^M ... and for x86_64: ... 0x4004a7
: 0x00004242^M ... Fix this by removing the "/h". Tested on x86_64-linux and s390x-linux. --- gdb/testsuite/gdb.base/write_mem.exp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/testsuite/gdb.base/write_mem.exp b/gdb/testsuite/gdb.base/write_mem.exp index a9e94032447..ce862a5bd34 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" "
:.*4242" +gdb_test "x /x main" "
:.*4242" set GDBFLAGS $old_gdbflags -- 2.30.2