Mattias,
I move our discussion to mailing list to get wider audience.
Recapitulation for others:
OpenOCD used to support old fashioned gdb remote protocol commands 'c' a
's' for resume and step.
These commands can also server as a native synchronization point between
OpenOCD and gdb.
Mattias implemented newer gdb protocol alternative vCont - it's
important step forward.
Unfortunately the new command lost the side effect of re-synchronization.
The first problem appears after gdb attach to a running target:
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0x00000000 in __isr_vector ()
(gdb)
Target is actually running but gdb thinks it is halted.
If target supports debug memory access in running state, gdb can inspect
memory.
Let's continue:
(gdb) c
Continuing.
target not halted
gdb thinks it just started the target. OpenOCD wanrs the user that it
not the case in reality
Anyway target has been runnnig so we get running state in sync. Up to
this point there is
no visible difference between the old code and the new vCont support.
Internally the problem starts here: gdb_connection->frontend_state was not
set to TARGET_RUNNING in vCont support.
Now we want to stop the target:
^C
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x000011dc msp: 0x2000ffe8
With the old code we would get gdb prompt here.
With vCont support only OpenOCD knows that target stopped.
gdb is not informed because gdb_frontend_halted() does not send
gdb_signal_reply()
if frontend_state is not TARGET_RUNNING.
On 24.02.2018 17:38, Matthias Welwarsky (Code Review) wrote:
Matthias Welwarsky has posted comments on this change. (
http://openocd.zylin.com/4432 )
Change subject: gdb_server: fix vCont
......................................................................
Patch Set 1:
I'd much rather fix the problem that causes the desync between gdb and openocd
than add a work-around for a not-so-well-understood odd behaviour. Unless gdb
is buggy, there should not be a reason for it to try resuming or stepping a
running target.
I'm afraid that having gdb state perfectly in sync with the target state
is mission impossible.
Attaching to a running target is only one example.
Another one: the target is stopped by gdb, user has a gdb prompt. Now
user presses the reset button and target runs again.
OpenOCD find it out on the next poll. But there is no way to inform gdb:
"Hey the target is running now - bail out the user prompt
and switch to run mode".
And just another: the target is stopped by gdb. User open telnet
interface and enters 'resume' or 'reset run'. Or issues the command
from gdb by 'monitor'.
*We really need a way to do resynchronization*. And resync on gdb
'continue' or 'step' commands offers a natural and simple way to do it.
BTW it worked for years. So don't treat the requirement of resync as an
workaround of not-so-well-understood odd behavior!!!
It is actually a vital feature for OpenOCD.
Tomas
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
