)]}'
{
  "commit": "24ac169ac5a918cd82b7485935f0c40a094c625e",
  "tree": "b9fe3b66663c525b292959333cf3770b27f8e6b5",
  "parents": [
    "22b6cd70430d6bdaa3ae6c01414de8fd1f15a556"
  ],
  "author": {
    "name": "Shahab Vahedi",
    "email": "shahab@synopsys.com",
    "time": "Wed Feb 19 14:56:02 2020 +0100"
  },
  "committer": {
    "name": "Shahab Vahedi",
    "email": "shahab@synopsys.com",
    "time": "Fri Feb 21 09:59:30 2020 +0100"
  },
  "message": "gdb/testsuite: Regenerate the testglue if it is not in\n\nFor running the  DejaGnu  tests,  some  esoteric  configurations\nmay require a testglue.   This,  for  instance,  is  true  about\ntesting ARC  targets  which  uses  its  own  DejaGnu  board  and\na simulator which does not support returning the program\u0027s  exit\ncode.  Therefore, for those  tests  that  use  \"gdb_compile\",  a\n\"gdb_tg.o\"  file  is  compiled  and  linked   into   the   final\nexecutable.\n\nThere  are  tests  that  invoke  \"gdb_compile\"  from   different\ndirectories.   Let\u0027s  take  a   look   at   an   example   test:\ngdb.base/fullname.exp.  The purpose of this  test  is  to  build\nthe executable from different directories (absolute vs. relative\nvs.  other) and then check if gdb can handle setting breakpoints\naccordingly.\n\nWhen  \"gdb_compile\"  generates  the  \"gdb_tg.o\",  it  does   not\ndo it again  for  the  same  test.   Although  this  might  seem\nefficient, it can lead to  problems  when  changing  directories\nbefore the next compile:\n\n  gdb compile failed, arc-elf32-gcc: error: gdb_tg.o:\n  No such file or directory\n\nThis patch checks if the wrapper file (\"gdb_tg.o\") is  still  in\nreach and if it is not, it will stimulate  the  regeneration  of\nthe wrapper.\n\nIt is worth mentioning that GCC\u0027s  DejaGnu  tests  handle  these\nscenarios as well and they seem to be more efficient in doing so\nby saving the library paths and manipulating them  if  necessary\n[1].  However, for GDB tests, that  require  less  compilations,\nI think the proposed solution should be fine compared to a  more\nfull fledged solution from GCC.  The glue file in  our  case  is\nonly 2 KiB.\n\nLast but not least, I ran the x86_64 tests on an x86_64 host and\nfound no regression.\n\n[1]\nAvid  coders  may  look  for  \"set_ld_library_path_env_vars\"  in\ngcc/testsuite/lib/target-libpath.exp.\n\ngdb/testsuite/ChangeLog:\n\n\t* lib/gdb.exp (gdb_wrapper_init): Reset\n\t\"gdb_wrapper_initialized\" to 0 if \"wrapper_file\" does\n\tnot exist.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "5553782e0a5282463c9b75fa98502c199fd7abb4",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/ChangeLog",
      "new_id": "6138a18f78226db85e3cd99800aa1629b7626efb",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/ChangeLog"
    },
    {
      "type": "modify",
      "old_id": "d8ebddf63cec14ffae109de80a33873f5d8798ea",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/lib/gdb.exp",
      "new_id": "81518b9646aec164846f39104b80403bdfdc465b",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/lib/gdb.exp"
    }
  ]
}