)]}'
{
  "commit": "ae6c314e014249a96c070eec58e5a2ae1cf103dc",
  "tree": "8fd967cd62eabe70fde473265ed86b0beec09f02",
  "parents": [
    "11f1fce44cbd0502ddf8e44bde949739ba1a87c3"
  ],
  "author": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Wed Jan 14 19:31:24 2026 +0000"
  },
  "committer": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Thu Jan 22 15:30:36 2026 +0000"
  },
  "message": "gdb/testsuite: fix failure in gdb.server/fetch-exec-and-args.exp\n\nBug PR gdb/33792 reported a gdb.server/fetch-exec-and-args.exp FAIL\nwhen using the native-gdbserver board:\n\n  FAIL: gdb.server/fetch-exec-and-args.exp: packet\u003don: set_remote_exec\u003dfalse: test_server_with_no_exec: show remote exec-file\n\nThe actual test output looks like this:\n\n  (gdb) show remote exec-file\n  The remote exec-file is unset, using automatic value \"/tmp/build/gdb/testsuite/outputs/gdb.server/fetch-exec-and-args/fetch-exec-and-args\".\n  (gdb) FAIL: gdb.server/fetch-exec-and-args.exp: packet\u003don: set_remote_exec\u003dfalse: test_server_with_no_exec: show remote exec-file\n\nThis test actually fails with native-gdbsever and\nnative-extended-gdbserver boards.  The problem is that these boards\nclear the sysroot.\n\nThis exact test has the following conditions:\n\n  + The qExecAndArgs is in use (see \u0027packet\u003don\u0027).\n\n  + We\u0027re not explicitly doing \u0027set remote exec-file ...\u0027 (see\n    \u0027set_remote_exec\u003dfalse\u0027).\n\n  + The test starts gdbserver without an executable (see\n    \u0027test_server_with_no_exec\u0027).\n\n  + And because of the native-gdbsever board, the sysroot is \"\".\n\nWhat this means is that GDB knows that gdbserver doesn\u0027t have an\nexecutable thanks to qExecAndArgs, the user hasn\u0027t set an executable\nfor GDB to use when starting a new inferior, but GDB does know that\nGDB and gdbserver can see the same filesystem due to the sysroot\nsetting.  GDB will then automatically use the current executable as\nthe remote executable name.  The test script doesn\u0027t expect this case,\nand so the test fails.\n\nFix this by adjusting the script to expect the \u0027using automatic value\n...\u0027 text when appropriate.\n\nI also extended the test_server_with_no_exec proc to take a new flag\n\u0027clear_sysroot\u0027, we now run the test with the sysroot set to \u0027target:\u0027\nand with the sysroot set to \"\", even when using the \u0027unix\u0027 board.\n\nAdditionally, I ran the test through check-all-boards and found one\nadditional failure, when using --host_board\u003dlocal-remote-host-native\nand --target_board\u003dlocal-remote-host-native.  In this case GDB copies\nthe executable to the remote host, which changes its filename.  When\nthe filename appears in the \u0027using automatic value ...\u0027 text, I was\nexpecting the filename assuming a local host.\n\nI could fix this, but it doesn\u0027t seem worth the extra complexity for\nthis one test, so I\u0027ve just set the test to be skipped for that one\nconfiguration.\n\nNow, when using check-all-boards, I\u0027m seeing no failures.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d33792\n\nApproved-By: Simon Marchi \u003csimon.marchi@efficios.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "d85cd94fb1dc7d90ce09194f79e6465bc5fea6f8",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.server/fetch-exec-and-args.exp",
      "new_id": "36189dec602b04a8d572fa2b4db06204e1c9a184",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.server/fetch-exec-and-args.exp"
    }
  ]
}