)]}'
{
  "commit": "0b63c811efc38f50b72422ed6a9db1de053e8736",
  "tree": "d5e6d50f133dbbc08e524221fcd12a306a16fd4a",
  "parents": [
    "2a8339b71f37f2d02f5b2194929c9d702ef27223"
  ],
  "author": {
    "name": "Simon Marchi",
    "email": "simon.marchi@polymtl.ca",
    "time": "Fri Nov 25 13:56:14 2022 -0500"
  },
  "committer": {
    "name": "Simon Marchi",
    "email": "simon.marchi@polymtl.ca",
    "time": "Fri Mar 17 16:34:25 2023 -0400"
  },
  "message": "gdb: introduce bp_loc_tracepoint\n\nSince commit cb1e4e32c2d9 (\"catch catch/throw/rethrow\", breakpoint -\u003e\ncatchpoint), this simple tracing scenario does not work:\n\n    $ gdb/gdb -nx -q --data-directory\u003dgdb/data-directory ./test\n    Reading symbols from ./test...\n    (gdb) tar rem :1234\n    Remote debugging using :1234\n    Reading symbols from /lib64/ld-linux-x86-64.so.2...\n    (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)\n    0x00007ffff7fe5730 in ?? () from /lib64/ld-linux-x86-64.so.2\n    (gdb) trace do_something\n    Tracepoint 1 at 0x555555555144: file test.c, line 5.\n    (gdb) tstart\n    (gdb) continue\n    Continuing.\n    Target returns error code \u002701\u0027.\n\nThe root cause is that the bp_location::nserted flag does not transfer\nanymore from an old bp_location to the new matching one.  When a shared\nlibrary gets loaded, GDB computes new breakpoint locations for each\nbreakpoint in update_breakpoint_locations.  The new locations are in the\nbreakpoint::loc chain, while the old locations are still in the\nbp_locations global vector.  Later, update_global_location_list is\ncalled.  It tries to map old locations to new locations, and if\nnecessary transfer some properties, like the inserted flag.\n\nSince commit cb1e4e32c2d9, the inserted flag isn\u0027t transferred for\nlocations of tracepoints.  This is because bl_address_is_meaningful used\nto be implemented like this:\n\n    static int\n    breakpoint_address_is_meaningful (struct breakpoint *bpt)\n    {\n      enum bptype type \u003d bpt-\u003etype;\n\n      return (type !\u003d bp_watchpoint \u0026\u0026 type !\u003d bp_catchpoint);\n    }\n\nand was changed to this:\n\n    static bool\n    bl_address_is_meaningful (bp_location *loc)\n    {\n      return loc-\u003eloc_type !\u003d bp_loc_other;\n    }\n\nBecause locations for tracepoints have the bp_loc_other type,\nbl_address_is_meaningful started to return false for them, where it\nreturned true before.  This made update_global_location_list skip the\npart where it calls swap_insertion.\n\nI think this can be solved by introduced a new bp_loc_tracepoint\nbp_loc_type.\n\nI don\u0027t know if it\u0027s accurate, but my understanding is that bp_loc_type\ndescribes roughly \"how do we ask the target to insert that location\".\nbp_loc_software_breakpoint are inserted using\ntarget_ops::insert_breakpoint_location.  bp_loc_hardware_breakpoint are\ninserted using target_ops::insert_hw_breakpoint.\nbp_loc_software_watchpoint and bp_loc_hardware_watchpoint are inserted\nusing target_ops::insert_watchpoint.  For all these, the address is\nmeaningful, as we ask the target to insert the point at a specific\naddress.  bp_loc_other is a catch-all for \"the rest\", in practice for\ncatchpoints that don\u0027t have a specific address (hence why\nbl_address_is_meaningful returns false for them).  For instance,\ninserting a signal catchpoint is done by asking the target to report\nthat specific signal.  GDB doesn\u0027t associate an address to that.\n\nBut tracepoints do have a meaningful address to thems, so they can\u0027t be\nbp_loc_other, with that logic.  They also can\u0027t be\nbp_loc_software_breakpoint, because we don\u0027t want GDB to insert\nbreakpoints for them (even though they might be implemented using\nsoftware breakpoints by the remote side).  So, the new bp_loc_tracepoint\ntype describes that the way to insert these locations is with\ntarget_ops::download_tracepoint.  It makes bl_address_is_meaningful\nreturn true for them.  And they\u0027ll be ignored by insert_bp_location and\nGDB won\u0027t try to insert a memory breakpoint for them.\n\nWith this, I see a few instances of \u0027Target returns error code: 01\u0027\ndisappearing from gdb.log, and the results of gdb.trace/*.exp improve a\nlittle bit:\n\n    -# of expected passes       3765\n    +# of expected passes       3781\n    -# of unexpected failures   518\n    +# of unexpected failures   498\n\nThings remain quite broken in that area though.\n\nChange-Id: Ic40935c450410f4bfaba397c9ebc7faf97320dd3\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "abee22cd162ce8bc3125f8ee3b80d2732415d6bd",
      "old_mode": 33188,
      "old_path": "gdb/breakpoint.c",
      "new_id": "51bea46256f28af10e7754e708b8e93c7d2aa4e3",
      "new_mode": 33188,
      "new_path": "gdb/breakpoint.c"
    },
    {
      "type": "modify",
      "old_id": "03aecd15eff6d93a8059bdcd9385dfa59096ab00",
      "old_mode": 33188,
      "old_path": "gdb/breakpoint.h",
      "new_id": "7c5cf3f2bef447679a101fb5a74555affae5548c",
      "new_mode": 33188,
      "new_path": "gdb/breakpoint.h"
    }
  ]
}