Bug 27439

Summary:	Detection of a running target/process
Product:	gdb	Reporter:	Anders Jansson <anders>
Component:	gdb	Assignee:	Not yet assigned to anyone <unassigned>
Status:	UNCONFIRMED ---
Severity:	normal	CC:	clyon, simark, tromey
Priority:	P2
Version:	8.3
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:

Description Anders Jansson 2021-02-19 09:51:51 UTC

Perhaps more of a question (sorry if on the wrong list!). 

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"?

Best Regards
Anders Jansson

Comment 1 Simon Marchi 2021-02-21 16:13:29 UTC

Off the top of my head, I don't think that kind of thing is supported right now.

Comment 2 Tom Tromey 2021-02-23 19:13:10 UTC

FWIW I imagine this would require some work on the gdb side as well.

Comment 3 Anders Jansson 2021-02-24 07:36:52 UTC

Thanks for the replies. At least not an obvious solution to this it seems.

Yes i guess it would require some work on the gdb side if additional RSP commands should be handled. For my use cases (at least as a starting point) i think it would be sufficient with a "polling" solution perhaps not requiring any extra RSP. If it was possible to issue a gdb command and make it reevaluate the target status. Then different MI frontends (Eclipse etc) could issue some sort of "refresh"-command periodically so the IDEs always presents the correct state.

1. GDB show target/core is in halted state.
2. Issue "refresh" command.
3. If target/core is running gdb is moved to running state (and sends the "running MI records"). Otherwise it do nothing.

Will do some experimenting. Only need to get into the GDB code first :)