)]}'
{
  "commit": "167f3beb655da160e9241e76b7f8b1855b30c903",
  "tree": "a3bf298f03a1b6dc47f5edb837ebe1939f6deb6d",
  "parents": [
    "b5661ff24f7111246b9e9b5f1cba5afe9d479daf"
  ],
  "author": {
    "name": "Tom de Vries",
    "email": "tdevries@suse.de",
    "time": "Mon Dec 12 14:25:58 2022 +0100"
  },
  "committer": {
    "name": "Tom de Vries",
    "email": "tdevries@suse.de",
    "time": "Mon Dec 12 14:25:58 2022 +0100"
  },
  "message": "[gdb/testsuite] Fix gdb.base/write_mem.exp for big endian\n\nOn s390x-linux (big endian), I run into:\n...\n(gdb) x /xh main^M\n0x1000638 \u003cmain\u003e:       0x0000^M\n(gdb) FAIL: gdb.base/write_mem.exp: x /xh main\n...\n\nIn contrast, on x86_64-linux (little endian), we have the expected:\n...\n(gdb) x /xh main^M\n0x4004a7 \u003cmain\u003e:        0x4242^M\n(gdb) PASS: gdb.base/write_mem.exp: x /xh main\n...\n\nThe problem is that the test-case hard-codes expectations about endiannes by\nwriting an int-sized value (4 bytes in this case) and then printing only a\nhalfword by using \"/h\" (so, two bytes).\n\nIf we print 4 bytes, we have for s390x:\n...\n0x1000638 \u003cmain\u003e:       0x00004242^M\n...\nand for x86_64:\n...\n0x4004a7 \u003cmain\u003e:        0x00004242^M\n...\n\nFix this by removing the \"/h\".\n\nTested on x86_64-linux and s390x-linux.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "a9e940324478fe696293237be24ce3e617f05f72",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.base/write_mem.exp",
      "new_id": "ce862a5bd34b21efa1757e4009d6fb8d8b0e8e37",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.base/write_mem.exp"
    }
  ]
}