diff options
author | Tom de Vries <tdevries@suse.de> | 2022-12-12 14:25:58 +0100 |
---|---|---|
committer | Tom de Vries <tdevries@suse.de> | 2022-12-12 14:25:58 +0100 |
commit | 167f3beb655da160e9241e76b7f8b1855b30c903 (patch) | |
tree | a3bf298f03a1b6dc47f5edb837ebe1939f6deb6d /binutils/dwarf.c | |
parent | b5661ff24f7111246b9e9b5f1cba5afe9d479daf (diff) | |
download | gdb-167f3beb655da160e9241e76b7f8b1855b30c903.zip gdb-167f3beb655da160e9241e76b7f8b1855b30c903.tar.gz gdb-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 'binutils/dwarf.c')
0 files changed, 0 insertions, 0 deletions