public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
From: gdb-buildbot@sergiodj.net
To: gdb-testers@sourceware.org
Subject: [binutils-gdb] Fix/Update misc comments
Date: Tue, 14 Jan 2020 15:29:00 -0000	[thread overview]
Message-ID: <7da6a5b938b426379f61e56e259a925bedfe242b@gdb-build> (raw)

*** TEST RESULTS FOR COMMIT 7da6a5b938b426379f61e56e259a925bedfe242b ***

commit 7da6a5b938b426379f61e56e259a925bedfe242b
Author:     Luis Machado <luis.machado@linaro.org>
AuthorDate: Fri Dec 6 18:12:37 2019 -0300
Commit:     Luis Machado <luis.machado@linaro.org>
CommitDate: Tue Jan 14 11:17:26 2020 -0300

    Fix/Update misc comments
    
    While doing some investigation of mine, i noticed a few typos,
    inaccuracies and missing information.
    
    I went ahead and updated/improved those.
    
    gdb/ChangeLog:
    
    2020-01-14  Luis Machado  <luis.machado@linaro.org>
    
            * inf-ptrace.c (inf_ptrace_target::resume): Update comments.
            * infrun.c (resume_1): Likewise.
            (handle_inferior_event): Remove stale comment.
            * linux-nat.c (linux_nat_target::resume): Update comments.
            (save_stop_reason): Likewise.
            (linux_nat_filter_event): Likewise.
            * linux-nat.h (struct lwp_info) <stop_pc>, <stop_reason>: Likewise.

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index fc4920ee64..545cfb36ce 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,13 @@
+2020-01-14  Luis Machado  <luis.machado@linaro.org>
+
+	* inf-ptrace.c (inf_ptrace_target::resume): Update comments.
+	* infrun.c (resume_1): Likewise.
+	(handle_inferior_event): Remove stale comment.
+	* linux-nat.c (linux_nat_target::resume): Update comments.
+	(save_stop_reason): Likewise.
+	(linux_nat_filter_event): Likewise.
+	* linux-nat.h (struct lwp_info) <stop_pc>, <stop_reason>: Likewise.
+
 2020-01-13  Andrew Burgess  <andrew.burgess@embecosm.com>
 
 	* elfread.c (record_minimal_symbol): Set section index to 0 for
diff --git a/gdb/inf-ptrace.c b/gdb/inf-ptrace.c
index ecd82ada4e..db17a76d94 100644
--- a/gdb/inf-ptrace.c
+++ b/gdb/inf-ptrace.c
@@ -354,10 +354,10 @@ inf_ptrace_target::resume (ptid_t ptid, int step, enum gdb_signal signal)
   if (step)
     {
       /* If this system does not support PT_STEP, a higher level
-         function will have called single_step() to transmute the step
-         request into a continue request (by setting breakpoints on
-         all possible successor instructions), so we don't have to
-         worry about that here.  */
+	 function will have called the appropriate functions to transmute the
+	 step request into a continue request (by setting breakpoints on
+	 all possible successor instructions), so we don't have to
+	 worry about that here.  */
       request = PT_STEP;
     }
 
diff --git a/gdb/infrun.c b/gdb/infrun.c
index a8636284f1..1312328b8f 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -2429,8 +2429,8 @@ resume_1 (enum gdb_signal sig)
   if (tp->control.trap_expected || bpstat_should_step ())
     tp->control.may_range_step = 0;
 
-  /* If enabled, step over breakpoints by executing a copy of the
-     instruction at a different address.
+  /* If displaced stepping is enabled, step over breakpoints by executing a
+     copy of the instruction at a different address.
 
      We can't use displaced stepping when we have a signal to deliver;
      the comments for displaced_step_prepare explain why.  The
@@ -2518,7 +2518,7 @@ resume_1 (enum gdb_signal sig)
       && step_over_info_valid_p ())
     {
       /* If we have nested signals or a pending signal is delivered
-	 immediately after a handler returns, might might already have
+	 immediately after a handler returns, might already have
 	 a step-resume breakpoint set on the earlier handler.  We cannot
 	 set another step-resume breakpoint; just continue on until the
 	 original breakpoint is hit.  */
@@ -5297,8 +5297,6 @@ Cannot fill $_exitsignal with the correct signal number.\n"));
       stop_waiting (ecs);
       return;
 
-      /* The following are the only cases in which we keep going;
-         the above cases end in a continue or goto.  */
     case TARGET_WAITKIND_FORKED:
     case TARGET_WAITKIND_VFORKED:
       /* Check whether the inferior is displaced stepping.  */
diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c
index 66004e5be8..e7533a9930 100644
--- a/gdb/linux-nat.c
+++ b/gdb/linux-nat.c
@@ -1700,7 +1700,8 @@ linux_nat_target::resume (ptid_t ptid, int step, enum gdb_signal signo)
   resume_many = (minus_one_ptid == ptid
 		 || ptid.is_pid ());
 
-  /* Mark the lwps we're resuming as resumed.  */
+  /* Mark the lwps we're resuming as resumed and update their
+     last_resume_kind to resume_continue.  */
   iterate_over_lwps (ptid, resume_set_callback);
 
   /* See if it's the current inferior that should be handled
@@ -2725,7 +2726,7 @@ save_stop_reason (struct lwp_info *lp)
 	    {
 	      /* If we determine the LWP stopped for a SW breakpoint,
 		 trust it.  Particularly don't check watchpoint
-		 registers, because at least on s390, we'd find
+		 registers, because, at least on s390, we'd find
 		 stopped-by-watchpoint as long as there's a watchpoint
 		 set.  */
 	      lp->stop_reason = TARGET_STOPPED_BY_SW_BREAKPOINT;
@@ -2929,7 +2930,7 @@ resumed_callback (struct lwp_info *lp)
 }
 
 /* Check if we should go on and pass this event to common code.
-   Return the affected lwp if we are, or NULL otherwise.  */
+   Return the affected lwp if we should, or NULL otherwise.  */
 
 static struct lwp_info *
 linux_nat_filter_event (int lwpid, int status)
@@ -3122,7 +3123,7 @@ linux_nat_filter_event (int lwpid, int status)
 
   /* Don't report signals that GDB isn't interested in, such as
      signals that are neither printed nor stopped upon.  Stopping all
-     threads can be a bit time-consuming so if we want decent
+     threads can be a bit time-consuming, so if we want decent
      performance with heavily multi-threaded programs, especially when
      they're using a high frequency timer, we'd better avoid it if we
      can.  */
diff --git a/gdb/linux-nat.h b/gdb/linux-nat.h
index e02611fcf1..f800e43997 100644
--- a/gdb/linux-nat.h
+++ b/gdb/linux-nat.h
@@ -229,7 +229,7 @@ struct lwp_info
 
   /* When 'stopped' is set, this is where the lwp last stopped, with
      decr_pc_after_break already accounted for.  If the LWP is
-     running, and stepping, this is the address at which the lwp was
+     running and stepping, this is the address at which the lwp was
      resumed (that is, it's the previous stop PC).  If the LWP is
      running and not stepping, this is 0.  */
   CORE_ADDR stop_pc;
@@ -238,7 +238,7 @@ struct lwp_info
   int step;
 
   /* The reason the LWP last stopped, if we need to track it
-     (breakpoint, watchpoint, etc.)  */
+     (breakpoint, watchpoint, etc.).  */
   enum target_stop_reason stop_reason;
 
   /* On architectures where it is possible to know the data address of


             reply	other threads:[~2020-01-14 15:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14 15:29 gdb-buildbot [this message]
2020-01-14 15:10 ` Failures on Ubuntu-Aarch64-native-gdbserver-m64, branch master gdb-buildbot
2020-01-16 17:53 ` Failures on Fedora-x86_64-m32, " gdb-buildbot
2020-01-16 17:53 ` Failures on Fedora-x86_64-cc-with-index, " gdb-buildbot
2020-01-16 18:31 ` Failures on Fedora-i686, " gdb-buildbot
2020-01-16 18:33 ` Failures on Fedora-x86_64-m64, " gdb-buildbot
2020-01-16 18:48 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " gdb-buildbot
2020-01-16 19:02 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " gdb-buildbot
2020-01-16 19:20 ` Failures on Fedora-x86_64-native-gdbserver-m32, " gdb-buildbot
2020-01-16 19:36 ` Failures on Fedora-x86_64-native-gdbserver-m64, " gdb-buildbot

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=7da6a5b938b426379f61e56e259a925bedfe242b@gdb-build \
    --to=gdb-buildbot@sergiodj.net \
    --cc=gdb-testers@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).