)]}'
{
  "commit": "e5b176f25ff51f6811b82f549b7524618d5c2f6b",
  "tree": "2f8edc639e385d0099180fd0a76f300cc25126d6",
  "parents": [
    "0e3b7c25eea80717638617ebafac611ed970def8"
  ],
  "author": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Tue Aug 31 14:04:11 2021 +0100"
  },
  "committer": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Tue Nov 30 12:10:40 2021 +0000"
  },
  "message": "gdb: make packet_command function available outside remote.c\n\nIn a later commit I will add a Python API to access the \u0027maint packet\u0027\nfunctionality, that is, sending a user specified packet to the target.\n\nTo make implementing this easier, this commit refactors how this\ncommand is currently implemented so that the packet_command function\nis now global.\n\nThe new global send_remote_packet function takes an object that is an\nimplementation of an abstract interface.  Two functions within this\ninterface are then called, one just before a packet is sent to the\nremote target, and one when the reply has been received from the\nremote target.  Using an interface object in this way allows (1) for\nthe error checking to be done before the first callback is made, this\nmeans we only print out what packet it being sent once we know we are\ngoing to actually send it, and (2) we don\u0027t need to make a copy of the\nreply if all we want to do is print it.\n\nOne user visible changes after this commit are the error\nmessages, which I\u0027ve changed to be less \u0027maint packet\u0027 command\nfocused, this will make them (I hope) better for when\nsend_remote_packet can be called from Python code.\n\nSo:      \"command can only be used with remote target\"\nBecomes: \"packets can only be sent to a remote target\"\n\nAnd:     \"remote-packet command requires packet text as argument\"\nBecomes: \"a remote packet must not be empty\"\n\nAdditionally, in this commit, I\u0027ve added support for packet replies\nthat contain binary data.  Before this commit, the code that printed\nthe reply treated the reply as a C string, it assumed that the string\nonly contained printable characters, and had a null character only at\nthe end.\n\nOne way to show the problem with this is if we try to read the auxv\ndata from a remote target, the auxv data is binary, so, before this\ncommit:\n\n  (gdb) target remote :54321\n  ...\n  (gdb) maint packet qXfer:auxv:read::0,1000\n  sending: \"qXfer:auxv:read::0,1000\"\n  received: \"l!\"\n  (gdb)\n\nAnd after this commit:\n\n  (gdb) target remote :54321\n  ...\n  (gdb) maint packet qXfer:auxv:read::0,1000\n  sending: \"qXfer:auxv:read::0,1000\"\n  received: \"l!\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\xf0\\xfc\\xf7\\xff\\x7f\\x00\\x00\\x10\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\xff\\xf\u003e\n  (gdb)\n\nThe binary contents of the reply are now printed as escaped hex.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "b55d9bc47f79a65e487b9c1a2bcc3dd73cfabb99",
      "old_mode": 33188,
      "old_path": "gdb/NEWS",
      "new_id": "09c5169e4ed36eccce449692c34ad490bd9c1abf",
      "new_mode": 33188,
      "new_path": "gdb/NEWS"
    },
    {
      "type": "modify",
      "old_id": "1a944b10ae52752fc720fbea138d7897a53131a7",
      "old_mode": 33188,
      "old_path": "gdb/doc/gdb.texinfo",
      "new_id": "738f2e4c0c7eefd1ef85f2c8fdeef4f3e992d9d5",
      "new_mode": 33188,
      "new_path": "gdb/doc/gdb.texinfo"
    },
    {
      "type": "modify",
      "old_id": "25a4d3cab6ecf81992bc6e82f388d3730b6a597d",
      "old_mode": 33188,
      "old_path": "gdb/remote.c",
      "new_id": "b4269809b4ed6deca528a7c5f7683644b8815a2e",
      "new_mode": 33188,
      "new_path": "gdb/remote.c"
    },
    {
      "type": "modify",
      "old_id": "46bfa01fc79bf03a3364dc7312564a7056d2b981",
      "old_mode": 33188,
      "old_path": "gdb/remote.h",
      "new_id": "0178294ab1d6fc95a49bc4255eb4efc9cf0b2a12",
      "new_mode": 33188,
      "new_path": "gdb/remote.h"
    }
  ]
}