)]}'
{
  "commit": "be0be9e7a8bf7252489ddecc8013ebc476bf3c55",
  "tree": "15442a40c873108bc45b9063de53d0b520f15a44",
  "parents": [
    "3296caafa31264bf2ea8f2ebd01efcd3caeb6a58"
  ],
  "author": {
    "name": "Tom Tromey",
    "email": "tromey@adacore.com",
    "time": "Tue Jun 30 10:09:48 2026 -0600"
  },
  "committer": {
    "name": "Tom Tromey",
    "email": "tromey@adacore.com",
    "time": "Fri Jul 17 10:19:14 2026 -0600"
  },
  "message": "Handle missing array descriptor in ada_type_of_array\n\nThe test case gdb.ada/mi_var_access.exp was failing with gnat-llvm.\nDebugging this, I found that the problem was that with gnat-llvm, the\narray descriptor would have a NULL pointer for the bounds when the\narray was invalidated.  That is, examining the object in C mode:\n\n    (gdb) p a_string_access\n    $1 \u003d {\n      P_ARRAY \u003d 0x0,\n      P_BOUNDS \u003d 0x0\n    }\n\nwhereas when using GNAT we see:\n\n    (gdb) print a_string_access\n    $1 \u003d {\n      P_ARRAY \u003d 0x0,\n      P_BOUNDS \u003d 0x402750\n    }\n\nThis was causing ada_type_of_array to return nullptr; with that\nbubbling up to varobj and then MI as a \"wrong\" type in the MI output.\n\nIt seems to me that a null P_BOUNDS is reasonable; and that this case\ncan be handled in ada_type_of_array by examining the type of P_BOUNDS\nwithout needing the bounds themselves.\n\nThe bound values are both set to 0 in this case, because\nexperimentally this is what is done at runtime in the GNAT-generated\ncode.  Perhaps an explicitly empty array (1/0) would be better; I am\nnot certain.\n\n\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "85b08af8c063af4b24b6e3cf2e84abecbfdf89c4",
      "old_mode": 33188,
      "old_path": "gdb/ada-lang.c",
      "new_id": "e057e49b7fc4e1db2fd081ccb2395d1f51cf3b1c",
      "new_mode": 33188,
      "new_path": "gdb/ada-lang.c"
    }
  ]
}