public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* gdb doesn't notice when a target resumes
@ 2022-05-04 19:46 Tim Newsome
  2022-05-05  8:58 ` Andrew Burgess
  0 siblings, 1 reply; 3+ messages in thread
From: Tim Newsome @ 2022-05-04 19:46 UTC (permalink / raw)
  To: gdb

In a setup like this:
gdb --- OpenOCD --- hardware target

I can download a program, debug, everything is fine. Let's say we're halted
somewhere.
Now something happens that causes the hardware target to be running again
and no longer halted. OpenOCD notices quickly because it polls the target.
But gdb doesn't ever notice that the target was resumed. There doesn't
appear to be a notification packet
<https://sourceware.org/gdb/onlinedocs/gdb/Notification-Packets.html#Notification-Packets>
for
OpenOCD to even communicate to gdb that the target has resumed.

Am I missing something? Have people attempted to tackle this problem?

Tim

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

* Re: gdb doesn't notice when a target resumes
  2022-05-04 19:46 gdb doesn't notice when a target resumes Tim Newsome
@ 2022-05-05  8:58 ` Andrew Burgess
  2022-05-06 17:45   ` Tim Newsome
  0 siblings, 1 reply; 3+ messages in thread
From: Andrew Burgess @ 2022-05-05  8:58 UTC (permalink / raw)
  To: Tim Newsome, gdb

Tim Newsome <tim@sifive.com> writes:

> In a setup like this:
> gdb --- OpenOCD --- hardware target
>
> I can download a program, debug, everything is fine. Let's say we're halted
> somewhere.
> Now something happens that causes the hardware target to be running again
> and no longer halted. OpenOCD notices quickly because it polls the target.
> But gdb doesn't ever notice that the target was resumed. There doesn't
> appear to be a notification packet
> <https://sourceware.org/gdb/onlinedocs/gdb/Notification-Packets.html#Notification-Packets>
> for
> OpenOCD to even communicate to gdb that the target has resumed.
>
> Am I missing something? Have people attempted to tackle this problem?

The following is my understanding, others might have a better
understanding that contradicts what I say here.

GDB expects to be the one driving the state of the target.  It's not
expected that the target will just resume execution without GDB being
the one to set the target resumed.

And that makes sense I think.  GDB is primarily a debugger.  If, as a
user, I stop the target in order to examine the state, and the hardware
suddenly resumes execution, that's a pretty poor user experience I
think.

Depending on what the "something" is that sets the target running, you
might have more luck if that "something" could instead tell GDB to
resume the target.

Otherwise you'd need to change GDB I think.  Maybe non-stop mode could
support the concept of the targtet asynchronously resuming... but I
suspect it would not be a trivial addition.

Thanks,
Andrew


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

* Re: gdb doesn't notice when a target resumes
  2022-05-05  8:58 ` Andrew Burgess
@ 2022-05-06 17:45   ` Tim Newsome
  0 siblings, 0 replies; 3+ messages in thread
From: Tim Newsome @ 2022-05-06 17:45 UTC (permalink / raw)
  To: Andrew Burgess; +Cc: gdb

Thanks, Andrew. That's pretty much my understanding too. In an ideal world
gdb would have full control of the hardware, but that's unfortunately not
the world we live in.

Tim

On Thu, May 5, 2022 at 1:58 AM Andrew Burgess <aburgess@redhat.com> wrote:

> Tim Newsome <tim@sifive.com> writes:
>
> > In a setup like this:
> > gdb --- OpenOCD --- hardware target
> >
> > I can download a program, debug, everything is fine. Let's say we're
> halted
> > somewhere.
> > Now something happens that causes the hardware target to be running again
> > and no longer halted. OpenOCD notices quickly because it polls the
> target.
> > But gdb doesn't ever notice that the target was resumed. There doesn't
> > appear to be a notification packet
> > <
> https://sourceware.org/gdb/onlinedocs/gdb/Notification-Packets.html#Notification-Packets
> >
> > for
> > OpenOCD to even communicate to gdb that the target has resumed.
> >
> > Am I missing something? Have people attempted to tackle this problem?
>
> The following is my understanding, others might have a better
> understanding that contradicts what I say here.
>
> GDB expects to be the one driving the state of the target.  It's not
> expected that the target will just resume execution without GDB being
> the one to set the target resumed.
>
> And that makes sense I think.  GDB is primarily a debugger.  If, as a
> user, I stop the target in order to examine the state, and the hardware
> suddenly resumes execution, that's a pretty poor user experience I
> think.
>
> Depending on what the "something" is that sets the target running, you
> might have more luck if that "something" could instead tell GDB to
> resume the target.
>
> Otherwise you'd need to change GDB I think.  Maybe non-stop mode could
> support the concept of the targtet asynchronously resuming... but I
> suspect it would not be a trivial addition.
>
> Thanks,
> Andrew
>
>

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

end of thread, other threads:[~2022-05-06 17:45 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-04 19:46 gdb doesn't notice when a target resumes Tim Newsome
2022-05-05  8:58 ` Andrew Burgess
2022-05-06 17:45   ` Tim Newsome

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).