)]}'
{
  "commit": "511aa7976d6e9acffd3cb974b431dbef06ec93cc",
  "tree": "13504c6add0e44f2ae80f882fb29272655e3d22d",
  "parents": [
    "6b4f72a01e60c854654a46f4faa555e258fa98b0"
  ],
  "author": {
    "name": "Tom de Vries",
    "email": "tdevries@suse.de",
    "time": "Mon May 26 15:15:31 2025 +0200"
  },
  "committer": {
    "name": "Tom de Vries",
    "email": "tdevries@suse.de",
    "time": "Mon May 26 15:15:31 2025 +0200"
  },
  "message": "[gdb] Partially stabilize sort in compare_{symbols,msymbols}\n\nIn compare_symbols in gdb/linespec.c:\n...\n  uia \u003d (uintptr_t) a.symbol-\u003esymtab ()-\u003ecompunit ()-\u003eobjfile ()-\u003epspace ();\n  uib \u003d (uintptr_t) b.symbol-\u003esymtab ()-\u003ecompunit ()-\u003eobjfile ()-\u003epspace ();\n\n  if (uia \u003c uib)\n    return true;\n  if (uia \u003e uib)\n     return false;\n...\nwe compare pointers to struct program_space, which gives unstable sorting\nresults.\n\nThe assumption is that this doesn\u0027t matter, but as PR32202 demonstrates,\nsometimes it does.\n\nWhile PR32202 is fixed elsewhere, it seems like a good idea to stabilize this\ncomparison, because it comes at a small cost and possibly prevents\nhard-to-reproduce user-visible ordering issues.\n\nFix this by comparing the program space IDs instead of the pointers.\n\nLikewise in compare_msymbols.\n\nTested on x86_64-linux.\n\nReviewed-By: Guinevere Larsen \u003cguinevere@redhat.com\u003e\nApproved-By: Andrew Burgess \u003caburgess@redhat.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "d42420ccfc2005d794eb5cecbe620f858a968577",
      "old_mode": 33188,
      "old_path": "gdb/linespec.c",
      "new_id": "53a59abfe90843e2155f9cd8584d94ae46f607d7",
      "new_mode": 33188,
      "new_path": "gdb/linespec.c"
    }
  ]
}