Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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, &param);
>   }
>
> +/* 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."?


  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