This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/9 v7] Introduce target_{stop,continue}_ptid
- From: Doug Evans <dje at google dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Gary Benson <gbenson at redhat dot com>, gdb-patches at sourceware dot org
- Date: Fri, 12 Sep 2014 09:53:50 -0700
- Subject: Re: [PATCH 3/9 v7] Introduce target_{stop,continue}_ptid
- Authentication-results: sourceware.org; auth=none
- References: <1409320299-6812-1-git-send-email-gbenson at redhat dot com> <1409320299-6812-4-git-send-email-gbenson at redhat dot com> <21520 dot 36381 dot 756875 dot 963606 at ruffy2 dot mtv dot corp dot google dot com> <20140911102659 dot GA17472 at blade dot nx> <5412DEB5 dot 6020706 at redhat dot com>
Pedro Alves writes:
> On 09/11/2014 11:26 AM, Gary Benson wrote:
> > Doug Evans wrote:
> >> Gary Benson writes:
> >>> This commit introduces two new functions to stop and restart
> >>> target processes that shared code can use and that clients must
> >>> implement. It also changes some shared code to use these
> >>> functions.
> >> [...]
> >>> +/* See target/target.h. */
> >>> +
> >>> +void
> >>> +target_continue_ptid (ptid_t ptid)
> >>> +{
> >>> + target_resume (ptid, 0, GDB_SIGNAL_0);
> >>> +}
> >>
> >> How come GDB_SIGNAL_0 is used here?
> >> Maybe it's correct, but it's not immediately clear.
> >>
> >> The reason I ask is because there are two ways to "continue"
> >> the inferior:
> >> 1) resume it where it left off, and if it stopped because
> >> of a signal then forward on that signal (assuming the
> >> signal is not "nopass") (GDB_SIGNAL_DEFAULT).
> >> 2) Either inject a new signal (GDB_SIGNAL_FOO) or cancel out
> >> a previously queued signal (GDB_SIGNAL_0).
> >>
> >> GDB_SIGNAL_0 is used to resume the target and discarding
> >> any signal that it may have stopped for.
> >> GDB_SIGNAL_DEFAULT is used for (1).
> >>
> >> I realize the comments for target_resume say to not pass
> >> GDB_SIGNAL_DEFAULT to it. But the name "target_continue_ptid"
> >> with no option to choose between (1) and (2)
> >> says to me "do what GDB_SIGNAL_DEFAULT" does.
>
> [...]
>
> For now, I think just documenting target_continue_ptid as
> resuming with no signal is good enough.
That may be sufficient for me to make this patch checkin-able,
but before then I'd like to understand how and where
this function will be used from gdb.
btw, how about target_continue_with_no_signal (ptid_t ptid) ?