Detection of a running target/process

[Simon Marchi]

On 2021-03-18 4:14 a.m., Anders Jansson wrote:
> Hi,
> 
> Created a BZ regarding this some time ago: https://sourceware.org/bugzilla/show_bug.cgi?id=27439
> 
> Will try this list and see if anyone has an idea.
> 
> As i understand it the RSP-protocol has the "stop reply" packets used by an RSP-stub/GDB-server to inform GDB-client that my debug target has stopped. But i cant find any information if its possible for an RSP-stub/GDB-server to inform the GDB-client if my debug target starts to execute by some external event not controlled by the GDB-client itself.
> 
> For example:
> * During a GDB session (target halted) i repower/reset an development board and the process starts to execute. Can GDB be notified about this?
> 
> * In a heterogeneous multi-core scenario where the starting/stopping of the cores are controlled by ARM cortex-M Cross Triggering. Different cores are controlled by multiple GDB-sessions. Perhaps the same issue as above. One GDB-session needs to get notified that the debug target started to execute.
> 
> Anyone know if there exists some RSP support for this. Some sort of "Running reply"?

Hi,

Pretty sure that doesn't exist upstream (or I missed it during all this
time).

Considering your first scenario (the simpler of both), it sounds
possible to implement on top of the non-stop variant of the remote
protocol, where notifications can be sent at any time (if I remember
correctly).  The most difficult would obviously be to adjust GDB's
internal state machine to account for it, and GDB may not currently be
listening to notifications from the remote side when everything is
stopped (because nothing can happen in that case, as of today).

This is not a definitive yes, but a "would be interesting to prototype"
:).

Simon