)]}'
{
  "commit": "dac3dbbf5e244c01d45bd1aa14e1e5cea7d5a63e",
  "tree": "6606031d542fb21414c1ce6eb9928678a4157f40",
  "parents": [
    "e607549f2495ed68da314642d5c4c51bdd470933"
  ],
  "author": {
    "name": "Simon Marchi",
    "email": "simon.marchi@efficios.com",
    "time": "Tue Dec 16 23:31:39 2025 -0500"
  },
  "committer": {
    "name": "Simon Marchi",
    "email": "simon.marchi@efficios.com",
    "time": "Wed Dec 17 15:11:17 2025 -0500"
  },
  "message": "gdb: replace msym_bunch with deque\n\nThis patch replaces the msym_bunch implementation with an std::deque.\n\nI initially tried to replace it with a vector.  However, that doesn\u0027t\nwork, because minimal_symbol references need to stay valid across calls\nto minimal_symbol_reader::record_full in at least one spot.\nelf_symtab_read calls minimal_symbol_reader::record_full (through\nfunction record_minimal_symbol) to record a minimal symbol for a PLT\nentry and then uses a previously added minimal symbol to set the size of\nthe PLT minimal symbol.  If we used a vector, a re-allocation could\nhappen which would invalidate the reference to the previous minimal\nsymbol (luckily this was caught by ASan).\n\nAn std::deque implementation typically uses a sequence of fixed-sized\narrays, much like our current msym_bunch implementation.  So adding an\nitem at the end will not invalidate existing references.  But unlike our\nmsym_bunch, we don\u0027t have to worry about memory management.\n\nI was a bit puzzled about this code in\nminimal_symbol_reader::record_full:\n\n  /* If we already read minimal symbols for this objfile, then don\u0027t\n     ever allocate a new one.  */\n  if (!m_objfile-\u003eper_bfd-\u003eminsyms_read)\n    {\n      m_msym_bunch_index++;\n      m_objfile-\u003eper_bfd-\u003en_minsyms++;\n    }\n\nFrom what I understand, this \"feature\" gets used when you have\nECOFF debug info in an ELF executable.  We first parse the ELF minimal\nsymbols in elf_symfile_read, then go into elfmdebug_build_psymtabs.\nelfmdebug_build_psymtabs has the capability to generate minimal symbols\n(useful when you use ECOFF debug info in an ECOFF executable I guess),\nbut in this case we already have the ELF ones, so we don\u0027t want to\nrecord the ECOFF minimal symbols.  Hence this mechanism to suppress new\nminimal symbols.\n\nThe consequence of this patch, I believe, is that\nminimal_symbol_reader::record_full will unnecessarily allocate minimal\nsymbols in this case.  These minimal symbols won\u0027t be installed, because\nof the check in minimal_symbol_reader::install.  The minimal symbols\nwill be freed when the minimal_symbol_reader gets destroyed.  That means\na higher temporary memory usage when reading an ECOFF-in-ELF file, but\nno change in behavior.  See discussion at [1].\n\n[1] https://inbox.sourceware.org/gdb-patches/85958fad-17e1-4593-b842-d60a6610f149@polymtl.ca/T/#meaf9b53da296e7f6872b441ec97038d172ca907f\n\nChange-Id: I7d10c6aca42cc9dcf80b483394e1e56351a9465f\nApproved-By: Tom Tromey \u003ctom@tromey.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "70f5f61748a6d2bc2946a3a85e4c0932ca38fa77",
      "old_mode": 33188,
      "old_path": "gdb/minsyms.c",
      "new_id": "1b1e43845778beb3faf4d38c7107b37a82d573ea",
      "new_mode": 33188,
      "new_path": "gdb/minsyms.c"
    },
    {
      "type": "modify",
      "old_id": "ed38044a38c620b6d76c75276eb533f8039cdbd7",
      "old_mode": 33188,
      "old_path": "gdb/minsyms.h",
      "new_id": "97be03953d57e52b7c0969e6cb595b75d15a91e3",
      "new_mode": 33188,
      "new_path": "gdb/minsyms.h"
    }
  ]
}