Detection of a running target/process

[Aktemur, Tankut Baris]

On Monday, March 29, 2021 6:39 PM, Simon Marchi Wrote:
> 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


Hi,

AFAIK, you have to create your remote target, define it as the target
of an inferior and attach to "something", so that GDB listens for events.
Once this is done, when the server reports in the stop reply a pid that is
not known to GDB, the remote target adds a new inferior (or re-uses an
existing one if that inferior's pid is 0).  So, if you can find that
"something" to attach to initially, the rest is relatively easy.  Just report
a stop reply for that new process when it becomes available.  To experiment
with it, you may want to initially attach to a dummy or an always-available
process.  Note that the server has to support multi-process for this work.
It's not a real solution to your needs, but may help for a start.

Regards
-Baris


Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928