From: Luis Machado <lgustavo@codesourcery.com>
To: Pedro Alves <palves@redhat.com>, <gdb-patches@sourceware.org>
Subject: Re: [PATCH 5/5] gdb: Coalesce/aggregate (async) vCont packets/actions
Date: Wed, 17 Feb 2016 13:42:00 -0000 [thread overview]
Message-ID: <56C478CD.6040900@codesourcery.com> (raw)
In-Reply-To: <1455677091-13683-6-git-send-email-palves@redhat.com>
I missed 5/5... Mostly nits, overall it looks sane to me.
On 02/17/2016 12:44 AM, Pedro Alves wrote:
> diff --git a/gdb/infrun.c b/gdb/infrun.c
> index 15210c9..f72937c 100644
> --- a/gdb/infrun.c
> +++ b/gdb/infrun.c
> @@ -2357,6 +2357,8 @@ do_target_resume (ptid_t resume_ptid, int step, enum gdb_signal sig)
> target_pass_signals ((int) GDB_SIGNAL_LAST, signal_pass);
>
> target_resume (resume_ptid, step, sig);
> +
> + target_do_resume ();
> }
>
I'm looking at the sequence of function names and they don't look too clear.
do_target_resume/target_resume/target_do_resume.
Should we have better names for these functions? Ones that make it more
explicit what each function is doing and the fact that we are
potentially defering resumptions? Like "queue_resume_actions" for
target_resume or "commit_resumption_actions" for target_do_resume?
> @@ -6200,6 +6555,56 @@ remove_new_fork_children (struct threads_listing_context *context)
> remove_child_of_pending_fork, ¶m);
> }
>
> +/* Check whether EVENT would prevent a global or process wildcard
> + vCont action. */
> +
> +static int
> +check_pending_event_prevents_wildcard_vcont_callback
> + (QUEUE (stop_reply_p) *q,
> + QUEUE_ITER (stop_reply_p) *iter,
> + stop_reply_p event,
> + void *data)
> +{
> + struct inferior *inf;
> + int *may_global_wildcard_vcont = (int *) data;
> +
> + if (event->ws.kind == TARGET_WAITKIND_NO_RESUMED
> + || event->ws.kind == TARGET_WAITKIND_NO_HISTORY)
> + return 1;
> +
> + if (event->ws.kind == TARGET_WAITKIND_FORKED
> + || event->ws.kind == TARGET_WAITKIND_VFORKED)
> + *may_global_wildcard_vcont = 0;
> +
> + inf = find_inferior_ptid (event->ptid);
> +
> + /* This may be the first time we heard about this process.
> + Regardless, we must not do a global wildcard resume, otherwise
> + we'd resume this process too. */
> + *may_global_wildcard_vcont = 0;
> + if (inf != NULL)
> + inf->priv->may_wildcard_vcont = 0;
> +
> + return 1;
> +}
> +
> +/* Check whether any event pending in the vStopped queue would prevent
> + a global or process wildcard vCont action. Clear
> + *may_global_wildcard if we can't do a global wildcard (vCont;c),
> + and clear the event inferior's may_wildcard_vcont flag if we can do
> + a process-wide wildcard resume (vCont;c:pPID.-1). */
> +
... inferior's may_wildcard_vcont flag if we can do ...
Can do or can't do?
> diff --git a/gdb/target.h b/gdb/target.h
> index 7c8513a..c40d1c7 100644
> --- a/gdb/target.h
> +++ b/gdb/target.h
> @@ -461,6 +461,8 @@ struct target_ops
> int TARGET_DEBUG_PRINTER (target_debug_print_step),
> enum gdb_signal)
> TARGET_DEFAULT_NORETURN (noprocess ());
> + void (*to_do_resume) (struct target_ops *)
> + TARGET_DEFAULT_IGNORE ();
> ptid_t (*to_wait) (struct target_ops *,
> ptid_t, struct target_waitstatus *,
> int TARGET_DEBUG_PRINTER (target_debug_print_options))
> @@ -1317,19 +1319,41 @@ extern void target_detach (const char *, int);
>
> extern void target_disconnect (const char *, int);
>
> -/* Resume execution of the target process PTID (or a group of
> - threads). STEP says whether to hardware single-step or to run free;
> - SIGGNAL is the signal to be given to the target, or GDB_SIGNAL_0 for no
> - signal. The caller may not pass GDB_SIGNAL_DEFAULT. A specific
> - PTID means `step/resume only this process id'. A wildcard PTID
> - (all threads, or all threads of process) means `step/resume
> - INFERIOR_PTID, and let other threads (for which the wildcard PTID
> - matches) resume with their 'thread->suspend.stop_signal' signal
> - (usually GDB_SIGNAL_0) if it is in "pass" state, or with no signal
> - if in "no pass" state. */
> -
> +/* Resume execution (or prepare for execution) of a target thread,
> + process or all processes. STEP says whether to hardware
> + single-step or to run free; SIGGNAL is the signal to be given to
> + the target, or GDB_SIGNAL_0 for no signal. The caller may not pass
> + GDB_SIGNAL_DEFAULT. A specific PTID means `step/resume only this
> + process id'. A wildcard PTID (all threads, or all threads of
> + process) means `step/resume INFERIOR_PTID, and let other threads
> + (for which the wildcard PTID matches) resume with their
> + 'thread->suspend.stop_signal' signal (usually GDB_SIGNAL_0) if it
> + is in "pass" state, or with no signal if in "no pass" state.
> +
> + In order to efficiently handle batches of resumption requests,
> + targets may implement this method such that it records the
> + resumption request, but defers the actual resumption to the
> + target_do_resume method implementation. See target_do_resume
> + below. */
> extern void target_resume (ptid_t ptid, int step, enum gdb_signal signal);
>
> +/* Commit a series of resumption requests previously prepared with
> + target_resume calls.
> +
> + GDB always call target_do_resume after calling target_resume or
> + more times. A target may thus use this method in coordination with
"GDB always calls ... target_resume one or more times."?
next prev parent reply other threads:[~2016-02-17 13:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-17 2:44 [PATCH 0/5] " Pedro Alves
2016-02-17 2:44 ` [PATCH 1/5] gdb: Clean up remote.c:remote_resume Pedro Alves
2016-02-17 11:45 ` Luis Machado
2016-02-17 12:32 ` Pedro Alves
2016-02-17 13:44 ` Luis Machado
2016-02-17 2:44 ` [PATCH 2/5] gdb: Free inferior->priv when inferior exits Pedro Alves
2016-02-17 2:44 ` [PATCH 3/5] gdb/doc: Clarify vCont packet description Pedro Alves
2016-02-17 15:56 ` Eli Zaretskii
2016-02-17 2:51 ` [PATCH 4/5] gdbserver: Leave already-vCont-resumed threads as they were Pedro Alves
2016-02-17 11:46 ` Luis Machado
2016-02-17 12:32 ` Pedro Alves
2016-10-26 15:39 ` Pedro Alves
2016-02-17 2:51 ` [PATCH 5/5] gdb: Coalesce/aggregate (async) vCont packets/actions Pedro Alves
2016-02-17 13:42 ` Luis Machado [this message]
2016-10-26 15:35 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56C478CD.6040900@codesourcery.com \
--to=lgustavo@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox