GDB is mostly used for user-space apps on linux using PTRACE. I would
suggest to obtain logs from GDB's interaction with user apps and mimic that
behavior here in OpenOCD stub.
On 25 February 2018 at 12:40, Tomas Vanek via OpenOCD-devel <
openocd-devel@lists.sourceforge.net> wrote:
> 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
> OpenOCD-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openocd-devel
>
>
------------------------------------------------------------------------------
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
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
