)]}'
{
  "commit": "146d4e2acecc4c34b3c0742e55e33653614a5ca1",
  "tree": "86918ef4905536c7b32f63f38186484df099a864",
  "parents": [
    "e5e7d55dcb225be1a488e01d43cbce5fdec83a0f"
  ],
  "author": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Tue Jan 28 10:08:28 2025 +0000"
  },
  "committer": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Wed Jan 29 09:46:15 2025 +0000"
  },
  "message": "gdbserver: introduce and use new gdb::argv_vec class\n\nIn gdbserver there are a couple of places where we perform manual\nmemory management using a \u0027std::vector\u003cchar *\u003e\u0027 with the vector owning\nthe strings within it.  We need to take care to call\nfree_vector_argv() before leaving the scope to cleanup the strings\nwithin the vector.\n\nThis commit introduces a new class gdb::argv_vec which wraps around a\n\u0027std::vector\u003cchar *\u003e\u0027 and owns the strings within the vector, taking\ncare to xfree() them when the gdb::argv_vec is destroyed.\n\nRight now I plan to use this class in gdbserver.\n\nBut this class will also be used to address review feedback on this\ncommit:\n\n  https://inbox.sourceware.org/gdb-patches/72227f1c5a2e350ca70b2151d1b91306a0261bdc.1736860317.git.aburgess@redhat.com\n\nwhere I tried to introduce another \u0027std::vector\u003cchar *\u003e\u0027 which owns\nthe strings.  That patch will be updated to use gdb::argv_vec instead.\n\nThe obvious question is, instead of introducing this new class, could\nwe change the APIs to avoid having a std::vector\u003cchar *\u003e that owns the\nstrings?  Could we use \u0027std::vector\u003cstd::string\u003e\u0027 or\n\u0027std::vector\u003cgdb::unique_xmalloc_ptr\u003cchar\u003e\u003e\u0027 instead?\n\nThe answer is yes we could.\n\nI originally posted this larger patch set:\n\n  https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com\n\nhowever, getting a 14 patch series reviewed is just not possible, so\ninstead, I\u0027m posting the patches one at a time.  The earlier patch I\nmentioned is pulled from the larger series.\n\nThe larger series already includes changes to gdbserver which removes\nthe need for the \u0027std::vector\u003cchar *\u003e\u0027, however, getting those changes\nin depends (I think) on the patch I mention above.  Hence we have a\nbit of a circular dependency.\n\nMy proposal is to merge this patch (adding gdb::argv_vec) and make use\nof it in gdbserver.\n\nThen I\u0027ll update the patch above to also use gdb::argv_vec, which will\nallow the above patch to get reviewed and merged.\n\nThen I\u0027ll post, and hopefully merge additional patches from my larger\ninferior argument series, which will remove the need for gdb::argv_vec\nfrom gdbserver.\n\nAt this point, the only use of gdb::argv_vec will be in the above\npatch, where I think it will remain, as I don\u0027t think that location\ncan avoid using \u0027std::vector\u003cchar *\u003e\u0027.\n\nApproved-By: Tom Tromey \u003ctom@tromey.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0ad27d5e83006ffdde2682dd3f2183dbcb07c99c",
      "old_mode": 33188,
      "old_path": "gdbserver/server.cc",
      "new_id": "33ff847bc5ce87d0ed11f15531dccb6d40e26381",
      "new_mode": 33188,
      "new_path": "gdbserver/server.cc"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "1f3b6dbb40e6a64a86bde1ea09fc06e3c50a4a41",
      "new_mode": 33188,
      "new_path": "gdbsupport/gdb_argv_vec.h"
    }
  ]
}