)]}'
{
  "commit": "9b381fd11184d1932c0eaefd83ee4ea5c7c280f9",
  "tree": "26b38a818b57d50815d1450bd4b18118c2ecb864",
  "parents": [
    "b601c58034ed755fb765fc13782b6876bffd25d4"
  ],
  "author": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Fri Jan 24 16:12:55 2025 +0000"
  },
  "committer": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Tue Jan 28 12:48:10 2025 +0000"
  },
  "message": "gdb/remote: add \u0027binary-upload\u0027 feature to guard \u0027x\u0027 packet use\n\nThis mailing list discussion:\n\n  https://inbox.sourceware.org/gdb-patches/CAOp6jLYD0g-GUsx7jhO3g8H_4pHkB6dkh51cbyDT-5yMfQwu+A@mail.gmail.com\n\nhighlighted the following issue with GDB\u0027s \u0027x\u0027 packet implementation.\n\nUnfortunately, LLDB also has an \u0027x\u0027 packet, but their implementation\nis different to GDB\u0027s and so targets that have implemented LLDB\u0027s \u0027x\u0027\npacket are incompatible with GDB.\n\nThe above thread is specifically about the \u0027rr\u0027 tool, but there could\nbe other remote targets out there that have this problem.\n\nThe difference between LLDB and GDB is that GDB expects a \u0027b\u0027 prefix\non the reply data, while LLDB does not.  The \u0027b\u0027 is important as it\nallows GDB to distinguish between an empty reply (which will be a \u0027b\u0027\nprefix with no trailing data) and an unsupported packet (which will be\na completely empty packet).  It is not clear to me how LLDB\ndistinguishes these two cases.\n\nSee for discussion of the \u0027x\u0027 packet:\n\n  https://inbox.sourceware.org/gdb-patches/cover.1710343840.git.tankut.baris.aktemur@intel.com/#r\n\nwith the part specific to the \u0027b\u0027 marker in:\n\n  https://inbox.sourceware.org/gdb-patches/87msq82ced.fsf@redhat.com/\n\nI propose that we add a new feature \u0027binary-upload\u0027 which can be\nreported by a stub in its qSupported reply.  By default this feature\nis \"off\", meaning GDB will not use the \u0027x\u0027 packet unless a stub\nadvertises this feature.\n\nI have updated gdbserver to send \u0027binary-upload+\u0027, and when I examine\nthe gdbserver log I can see this feature being sent back, and then GDB\nwill use the \u0027x\u0027 packet.\n\nWhen connecting to an older gdbserver, the feature is not sent, and\nGDB does not try to use the \u0027x\u0027 packet at all.\n\nI also built the latest version of `rr` and tested using current HEAD\nof master, where I see problems like this:\n\n  (rr) x/10i main\n     0x401106 \u003cmain\u003e:   Cannot access memory at address 0x401106\n\nThen tested using this patched version of GDB, and now I see:\n\n  (rr) x/10i main\n     0x401106 \u003cmain\u003e:   push   %rbp\n     0x401107 \u003cmain+1\u003e: mov    %rsp,%rbp\n     0x40110a \u003cmain+4\u003e: mov    0x2f17(%rip),%rax        # 0x404028 \u003cglobal_ptr\u003e\n     ... etc ...\n\nand looking in the remote log I see GDB is now using the \u0027m\u0027 packet\ninstead of the \u0027x\u0027 packet.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d32593\nReviewed-By: Eli Zaretskii \u003celiz@gnu.org\u003e\nReviewed-By: Tankut Baris Aktemur \u003ctankut.baris.aktemur@intel.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "3db90719917e5e46402f691dd994d0685953d07e",
      "old_mode": 33188,
      "old_path": "gdb/NEWS",
      "new_id": "e678de55ce64771cb53adda2be58ac032abed6cd",
      "new_mode": 33188,
      "new_path": "gdb/NEWS"
    },
    {
      "type": "modify",
      "old_id": "2909fc71510c4f7ae9a61d117c8702e5f10b7444",
      "old_mode": 33188,
      "old_path": "gdb/doc/gdb.texinfo",
      "new_id": "ff9fe298be32b4d6a75220d91500d9944edc4e99",
      "new_mode": 33188,
      "new_path": "gdb/doc/gdb.texinfo"
    },
    {
      "type": "modify",
      "old_id": "64622dbfcdfc1dc3b733d5851ea7310663366bba",
      "old_mode": 33188,
      "old_path": "gdb/remote.c",
      "new_id": "f3687fbaa70c41f8261f4897d0a7e4f6512b1e2a",
      "new_mode": 33188,
      "new_path": "gdb/remote.c"
    },
    {
      "type": "modify",
      "old_id": "c1b18cc947e85617287da2be3e2e4487b2e4c10c",
      "old_mode": 33188,
      "old_path": "gdbserver/server.cc",
      "new_id": "0ad27d5e83006ffdde2682dd3f2183dbcb07c99c",
      "new_mode": 33188,
      "new_path": "gdbserver/server.cc"
    }
  ]
}