Reponse to 'start' in extended-remote mode

[mubes]

Hi, apologies if this is already dealt with, or if the question should be asked elsewhere. I am connecting to pyocd (0.28.1dev) via target extended-remote localhost:3333 and after loading an application would like to start it with the start command. At the pyocd end I receive the following packets;

b'$vKill;a410#33'
b'$k#6b'
b'$?#3f'

and at the gdb end (8.3.0.20190709-git from GNU Tools for Arm Embedded Processors 9-2019-q4-major) I get the following interaction;

(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Sending packet: $vKill;a410#33...Packet received: 
Packet vKill (kill) is NOT supported
Sending packet: $k#6b...Sending packet: $?#3f...Packet received: 
Sending packet: $Hg0#df...Temporary breakpoint 1 at 0x8007900: main. (2 locations)
Starting program: ofiles/firmware.elf 
Segmentation fault (core dumped)

Obviously something isn't quite behaving properly, but I don't exactly know what. I should point out that I'm developing a new cmsis-dap interface so it could be a problem on my end (it works OK in non-extended mode). If you could find the time, could you please let me know if pyocd supports extended-remote and, if so, what the expected protocol flow would be for this case? That will greatly help me chase down this problem. Thanks in advance DAVE

[flit]

Looks like this is a mix of multiple issues.

First, the start command is primarily intended for process-oriented debugging. It's not normally used with remote embedded targets, as gdb considers those targets to always be running.

The canonical way to begin a debug session with pyOCD (or OpenOCD) is:

(gdb) b main
(gdb) load
(gdb) mon reset halt
# run 'flushregs' here if you want to examine the target before continuing to main
(gdb) c

When you issue start, gdb tries to kill the current process by sending the vKill command, but it sends some nonsensical process ID. (What's weird is that gdb should not be sending vKill because pyocd hasn't indicated support for it, but when that fails gdb falls back to the k command.)

It looks like there are a couple issues in pyocd's extended remote handling. Basically, it's exiting when it shouldn't be in response to some of these commands. That might be why gdb crashes, not sure.

[mubes]

Hi Chris,

The only reason I was looking at this was for robustness testing on my cmsis-dap implementation. Both Blackmagic and Segger cope with extended-remote so I was just trying out comparable things to what I do on those. In consequence the start and run commands make sense when using those probes.

I guess, pyocd could 'can' a sequence of instructions like the above to implement the extended functionality. The main argument for using it for an embedded target that I've heard from the BMP community is that it keeps the state of the target consistent from the perspective of gdb (obviously, monitor commands are working under the covers as far as it's concerned). Confusingly, my gdb still issues vKill attempts even in non-extended mode! I can only think that is because my caps includes multiprocess;

$qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df

I don't much mind how we resolve this provided that, in the end, nothing crashes :-) Personally, it would be perfectly OK with me if pyocd simply rejected an extended-remote connection attempt but I've just looked at the protocol flow for remote and extended-remote and, frustratingly, I don't see any difference between them (well, there's one empty packet sent in the extended-remote case, but that's no basis for decision making), so that's not really going to fly.

If you have a candidate patch or wish to discuss further I'll happily help.

Regards

DAVE