)]}'
{
  "commit": "e2fe3cbd0cd11f536261ef2e283dd704ed30c7a4",
  "tree": "151b6e6a854c9ccac09690cc0df1d5739e056a7f",
  "parents": [
    "4de4e48514fc47aeb4ca95cd4091e2a333fbe9e1"
  ],
  "author": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Mon May 15 17:54:55 2023 +0100"
  },
  "committer": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Tue May 16 10:35:41 2023 +0100"
  },
  "message": "gdb/testsuite: fix regressions in break-main-file-remove-fail.exp\n\nAfter this commit:\n\n  commit a68f7e9844208ad8cd498f89b5100084ece7d0f6\n  Date:   Tue May 9 10:28:42 2023 +0100\n\n      gdb/testsuite: extend special \u0027^\u0027 handling to gdb_test_multiple\n\nbuildbot notified me of a regression on s390 in the test:\n\n  gdb.base/break-main-file-remove-fail.exp\n\nthe failure looks like this:\n\n  print /d ((int (*) (void *, size_t)) munmap) (16781312, 4096)\n  warning: Error removing breakpoint 0\n  $2 \u003d 0\n  (gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: get integer valueof \"((int (*) (void *, size_t)) munmap) (16781312, 4096)\"\n\nOn the mailing list it has been reported that this failure also\nimpacts arm, aarch64, and possibly ppc/ppc64 too.\n\nThe above commit changed get_integer_valueof so that no output is\nexpected between the command and the \u0027$2 \u003d 0\u0027 line.  In this case the\n\u0027warning: Error removing breakpoint 0\u0027 output is causing the\nget_integer_valueof call to fail.\n\nThe reason for this warning is that this test deliberately calls\nmunmap on a page of the inferior\u0027s code.  The test is checking that\nGDB can handle the situation where a s/w breakpoint can\u0027t be\nremoved (due to the page no longer being readable/writable).\n\nThe test that is supposed to trigger the warning is later in the test\nscript when we delete a breakpoint.\n\nSo why do some targets trigger the warning earlier during the inferior\ncall?\n\nThe impacted targets use AT_ENTRY_POINT as their strategy for handling\ninferior calls, that is, the trampoline that calls the inferior\nfunction is placed at the program\u0027s entry point, e.g. often the _start\nlabel.\n\nIf this location happens to be on the same page as the page that the\ntest script unmaps then, when the inferior function call returns, GDB\nwill not be able to remove the temporary breakpoint that is inserted\nto catch the inferior function call returning!  As a result we end up\nseeing the warning earlier than expected.\n\nI did wonder if this means I should relax the pattern in\nget_integer_valueof - just accept that there might be additional\noutput from GDB which we should ignore.\n\nHowever, I don\u0027t think this the right way to go.  With the change in\na68f7e984420 we are now stricter for GDB emitting additional,\nunexpected, output, and I think that is a good thing.\n\nSo, I think, in this case, in order to handle the possible extra\noutput, we should implement something like get_integer_valueof\ndirectly in the gdb.base/break-main-file-remove-fail.exp test script.\nThis local version will handle the possible warning output.\n\nAfter this the test should pass again on the impacted targets.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "66ccc60a21a3b376ad7564eef8a6955edbce7b47",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.base/break-main-file-remove-fail.exp",
      "new_id": "c7cf4f3df00ff83f649f046fd63db3a7339073bc",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.base/break-main-file-remove-fail.exp"
    }
  ]
}