)]}'
{
  "commit": "d4b42011bcd418f7c0cfda81223639e0d636352d",
  "tree": "2533f468ced3b25904af5c76b6cbbe9c3aacec2e",
  "parents": [
    "45311dce11671fd265e7468e961b3ad5b9204b9e"
  ],
  "author": {
    "name": "Tom Tromey",
    "email": "tom@tromey.com",
    "time": "Wed Nov 19 02:42:34 2025 -0700"
  },
  "committer": {
    "name": "Tom Tromey",
    "email": "tom@tromey.com",
    "time": "Sun Nov 23 11:28:10 2025 -0700"
  },
  "message": "Remove a call to blockvector::map\n\nblock_starting_point_at checks blockvector::map before doing a lookup.\n\nThis patch removes this call, a step toward making the blockvector API\na bit more opaque.  It arranges to find the necessary blockvector just\nonce, in gather_inline_frames, and then uses the \u0027lookup\u0027 method to\nfind the desired block.\n\nNote that this is a slight change of semantics, in that the old code\nlooked only in the map while the new code looks in the blockvector,\nregardless of whether a map was made.  However, I don\u0027t think this\nshould matter, and furthermore this seems like an abstraction\nviolation, with the inline-frame code knowing details of how buildsym\ndecided to create the blockvector.\n\nin the longer run, I think only the \u0027lookup\u0027 method should be provided\nby blockvector -- that is, separately checking the map should be\nimpossible.  The idea here is that eventually, for lazy CU expansion,\nwe will want to be able to expand the blockvector.  This may be easier\nwith a different underlying data structure, so perhaps the map will go\naway entirely.  After this patch, one such use remains.\n\nRegression tested on x86-64 Fedora 40.\n\nApproved-by: Kevin Buettner \u003ckevinb@redhat.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "5ec18e90547fe9471324b4f343058d58ac9c8d35",
      "old_mode": 33188,
      "old_path": "gdb/inline-frame.c",
      "new_id": "649acab579311988b91e8e6254a4ade67931085e",
      "new_mode": 33188,
      "new_path": "gdb/inline-frame.c"
    }
  ]
}