wishbone-tool gdbserver isn't unescaping binary payloads

[zyp]

Per GDB remote protocol overview:

Some packets designed more recently assume an eight-bit clean connection, and use a more efficient encoding to send and receive binary data.

The binary data representation uses 7d (ASCII ‘}’) as an escape character. Any escaped byte is transmitted as the escape character followed by the original character XORed with 0x20. For example, the byte 0x7d would be transmitted as the two bytes 0x7d 0x5d. The bytes 0x23 (ASCII ‘#’), 0x24 (ASCII ‘$’), and 0x7d (ASCII ‘}’) must always be escaped. Responses sent by the stub must also escape 0x2a (ASCII ‘*’), so that it is not interpreted as the start of a run-length encoded sequence (described next).

One of the packets using binary data is the X packet for writing memory, used by the GDB load command.

wishbone-tool doesn't appear to be unescaping the binary data before writing memory; when using GDB to load a file of incrementing numbers into ram, this is the resulting memory contents:

0x20000000:     0x00    0x01    0x02    0x03    0x04    0x05    0x06    0x07
0x20000008:     0x08    0x09    0x0a    0x0b    0x0c    0x0d    0x0e    0x0f
0x20000010:     0x10    0x11    0x12    0x13    0x14    0x15    0x16    0x17
0x20000018:     0x18    0x19    0x1a    0x1b    0x1c    0x1d    0x1e    0x1f
0x20000020:     0x20    0x21    0x22    0x7d    0x03    0x7d    0x04    0x25
0x20000028:     0x26    0x27    0x28    0x29    0x7d    0x0a    0x2b    0x2c
0x20000030:     0x2d    0x2e    0x2f    0x30    0x31    0x32    0x33    0x34
0x20000038:     0x35    0x36    0x37    0x38    0x39    0x3a    0x3b    0x3c
0x20000040:     0x3d    0x3e    0x3f    0x40    0x41    0x42    0x43    0x44
0x20000048:     0x45    0x46    0x47    0x48    0x49    0x4a    0x4b    0x4c
0x20000050:     0x4d    0x4e    0x4f    0x50    0x51    0x52    0x53    0x54
0x20000058:     0x55    0x56    0x57    0x58    0x59    0x5a    0x5b    0x5c
0x20000060:     0x5d    0x5e    0x5f    0x60    0x61    0x62    0x63    0x64
0x20000068:     0x65    0x66    0x67    0x68    0x69    0x6a    0x6b    0x6c
0x20000070:     0x6d    0x6e    0x6f    0x70    0x71    0x72    0x73    0x74
0x20000078:     0x75    0x76    0x77    0x78    0x79    0x7a    0x7b    0x7c
0x20000080:     0x7d    0x5d    0x7e    0x7f    0x80    0x81    0x82    0x83
0x20000088:     0x84    0x85    0x86    0x87    0x88    0x89    0x8a    0x8b
0x20000090:     0x8c    0x8d    0x8e    0x8f    0x90    0x91    0x92    0x93
0x20000098:     0x94    0x95    0x96    0x97    0x98    0x99    0x9a    0x9b
0x200000a0:     0x9c    0x9d    0x9e    0x9f    0xa0    0xa1    0xa2    0xa3
0x200000a8:     0xa4    0xa5    0xa6    0xa7    0xa8    0xa9    0xaa    0xab
0x200000b0:     0xac    0xad    0xae    0xaf    0xb0    0xb1    0xb2    0xb3
0x200000b8:     0xb4    0xb5    0xb6    0xb7    0xb8    0xb9    0xba    0xbb
0x200000c0:     0xbc    0xbd    0xbe    0xbf    0xc0    0xc1    0xc2    0xc3
0x200000c8:     0xc4    0xc5    0xc6    0xc7    0xc8    0xc9    0xca    0xcb
0x200000d0:     0xcc    0xcd    0xce    0xcf    0xd0    0xd1    0xd2    0xd3
0x200000d8:     0xd4    0xd5    0xd6    0xd7    0xd8    0xd9    0xda    0xdb
0x200000e0:     0xdc    0xdd    0xde    0xdf    0xe0    0xe1    0xe2    0xe3
0x200000e8:     0xe4    0xe5    0xe6    0xe7    0xe8    0xe9    0xea    0xeb
0x200000f0:     0xec    0xed    0xee    0xef    0xf0    0xf1    0xf2    0xf3
0x200000f8:     0xf4    0xf5    0xf6    0xf7    0xf8    0xf9    0xfa    0xfb
0x20000100:     0xfc    0xfd    0xfe    0xff    0x00    0x01    0x02    0x03

[mithro]

@PiotrZierhoffer / @kgugala - You might find this topic interesting....