GDB server responds with '9+' to unsupported command

[thedjnK]

Testing https://github.com/Linaro/aerology with a DAPLINK via pyocd GDB server to an nRF52840 target reveals an interesting result, aerology sends a command which pyocd does not support qXfer:features:read:arm-m-profile.xml:0,1000, but the response that it sends back is 9+, where the 9 is unexpected. This causes the aerology program to wait for data which never arrives, verbose output from pyocd:

0028146:DEBUG:packet_io:Starting GDB server packet I/O thread
0028146:DEBUG:cortex_m:halting core 0
0028147:INFO:gdbserver:Client connected to port 3333!
0028147:DEBUG:gdbserver:GDB received query: [b'Supported#37']
0028147:DEBUG:gdbserver:GDB received query: [b'Xfer', b'features', b'read', b'target.xml', b'0,1000#0c']
0028147:DEBUG:gdbserver:GDB query b'read_feature': offset: 0, size: 4096
0028148:DEBUG:gdbserver:GDB received query: [b'Xfer', b'features', b'read', b'arm-m-profile.xml', b'0,1000#79']
0028148:DEBUG:gdbserver:Unsupported qXfer request: b'features':b'read':b'arm-m-profile.xml':b'0,1000#79'

strace showing strange response:

socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
ioctl(3, FIONBIO, [1])                  = 0
connect(3, {sa_family=AF_INET, sin_port=htons(3333), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
ioctl(3, FIONBIO, [0])                  = 0
poll([{fd=3, events=POLLOUT}], 1, 99)   = 1 ([{fd=3, revents=POLLOUT}])
sendto(3, "$qSupported#37", 14, MSG_NOSIGNAL, NULL, 0) = 14
recvfrom(3, "+", 1024, 0, NULL, NULL)   = 1
recvfrom(3, "$#00", 1024, 0, NULL, NULL) = 4
sendto(3, "+", 1, MSG_NOSIGNAL, NULL, 0) = 1
sendto(3, "$qXfer:features:read:target.xml:"..., 41, MSG_NOSIGNAL, NULL, 0) = 41
recvfrom(3, "+", 1024, 0, NULL, NULL)   = 1
recvfrom(3, "$m<?xml version=\"1.0\"?>\n<!DOCTYP"..., 1024, 0, NULL, NULL) = 1024
recvfrom(3, "tsize=\"32\" type=\"data_ptr\" group"..., 1024, 0, NULL, NULL) = 1024
sendto(3, "+", 1, MSG_NOSIGNAL, NULL, 0) = 1
sendto(3, "$qXfer:features:read:arm-m-profi"..., 48, MSG_NOSIGNAL, NULL, 0) = 48
recvfrom(3, "9+", 1024, 0, NULL, NULL)  = 2
recvfrom(3,

This is with pyocd 0.31.0, I've upgraded to 0.33.1 and the bug still seems present, it just puts the '9' and '+' in separate responses:

0000886 D Running task notify [sequencer]
0000887 D Setting vector catch to 0x00000001 [cortex_m]
0000889 I Semihost server started on port 4444 (core 0) [server]
0000904 I GDB server started on port 3333 (core 0) [gdbserver]
0004863 D Starting GDB server packet I/O thread [packet_io]
0004863 D halting core 0 [cortex_m]
0004864 I Client connected to port 3333! [gdbserver]
0004864 D GDB received query: [b'Supported#37'] [gdbserver]
0004864 D GDB received query: [b'Xfer', b'features', b'read', b'target.xml', b'0,1000#0c'] [gdbserver]
0004864 D GDB query b'read_feature': offset: 0, size: 4096 [gdbserver]
0004864 D GDB received query: [b'Xfer', b'features', b'read', b'arm-m-profile.xml', b'0,1000#79'] [gdbserver]
0004864 D Unsupported qXfer request: b'features':b'read':b'arm-m-profile.xml':b'0,1000#79' [gdbserver]

strace log:

poll([{fd=3, events=POLLOUT}], 1, 99)   = 1 ([{fd=3, revents=POLLOUT}])
sendto(3, "$qSupported#37", 14, MSG_NOSIGNAL, NULL, 0) = 14
recvfrom(3, "+", 1024, 0, NULL, NULL)   = 1
recvfrom(3, "$#00", 1024, 0, NULL, NULL) = 4
sendto(3, "+", 1, MSG_NOSIGNAL, NULL, 0) = 1
sendto(3, "$qXfer:features:read:target.xml:"..., 41, MSG_NOSIGNAL, NULL, 0) = 41
recvfrom(3, "+", 1024, 0, NULL, NULL)   = 1
recvfrom(3, "$m<?xml version=\"1.0\"?>\n<!DOCTYP"..., 1024, 0, NULL, NULL) = 1024
recvfrom(3, "tsize=\"32\" type=\"data_ptr\" group"..., 1024, 0, NULL, NULL) = 1024
sendto(3, "+", 1, MSG_NOSIGNAL, NULL, 0) = 1
sendto(3, "$qXfer:features:read:arm-m-profi"..., 48, MSG_NOSIGNAL, NULL, 0) = 48
recvfrom(3, "9+", 1024, 0, NULL, NULL)  = 2
recvfrom(3,

According to the GDB remote serial protocol, it should respond with an empty packet if the command is unsupported

[flit]

(Apologies for taking so long to reply! 🙇🏽)

Thanks for the report. Interesting and odd that aerology requests arm-m-profile.xml. That file is defined within gdb, but gdb itself never asks for it and only uses it internally from the Arm tdesc.

The issue is pretty clear in the pyocd code. It's got a fixed check for target.xml. Not sure where the "9" comes from, will have to debug to resolve that.

[flit]

@thedjnK Could you please test the fix in #1414 before I merge it?

You can install the fix with:

pip install git+https://github.com/pyocd/pyOCD@refs/pull/1414/merge

I didn't take the time to figure out where the "9" came from, but the gdbserver should reply with valid packets (or empty packets as required) in all cases.

[flit]

Closing, should be fixed now.