public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Detection of a running target/process
@ 2021-03-18  8:14 Anders Jansson
  2021-03-29 16:39 ` Simon Marchi
  0 siblings, 1 reply; 2+ messages in thread
From: Anders Jansson @ 2021-03-18  8:14 UTC (permalink / raw)
  To: gdb

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

Thanks in advance
Anders Jansson



-- 
Anders Jansson
Software Engineer

JanssonSoftware AB
Hansinggatan 42 | SE-50753 Borås | Sweden
Mobile +46 (0)76 8184622


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Detection of a running target/process
  2021-03-18  8:14 Detection of a running target/process Anders Jansson
@ 2021-03-29 16:39 ` Simon Marchi
  0 siblings, 0 replies; 2+ messages in thread
From: Simon Marchi @ 2021-03-29 16:39 UTC (permalink / raw)
  To: Anders Jansson, gdb

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-03-29 16:39 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-18  8:14 Detection of a running target/process Anders Jansson
2021-03-29 16:39 ` Simon Marchi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).