[binutils-gdb] [gdb/testsuite] Fix gdb.base/write_mem.exp for big endian

[binutils-gdb] [gdb/testsuite] Fix gdb.base/write_mem.exp for big endian

[Tom de Vries]

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=167f3beb655da160e9241e76b7f8b1855b30c903

commit 167f3beb655da160e9241e76b7f8b1855b30c903
Author: Tom de Vries <tdevries@suse.de>
Date:   Mon Dec 12 14:25:58 2022 +0100

    [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.

Diff:
---
 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" "<main>:.*4242"
+gdb_test "x /x main" "<main>:.*4242"
 
 set GDBFLAGS $old_gdbflags