Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yao Qi <qiyaoltc@gmail.com>
To: gdb-patches@sourceware.org
Subject: [PATCH 02/13] Re-indent the code
Date: Tue, 18 Aug 2015 15:53:00 -0000	[thread overview]
Message-ID: <1439913199-22882-3-git-send-email-yao.qi@linaro.org> (raw)
In-Reply-To: <1439913199-22882-1-git-send-email-yao.qi@linaro.org>

gdb/gdbserver:

2015-08-18  Yao Qi  <yao.qi@linaro.org>

	* linux-aarch64-low.c (debug_reg_change_callback): Re-indent
	the code.
---
 gdb/gdbserver/linux-aarch64-low.c | 66 +++++++++++++++++++--------------------
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/gdb/gdbserver/linux-aarch64-low.c b/gdb/gdbserver/linux-aarch64-low.c
index d39a54f..8b59eab 100644
--- a/gdb/gdbserver/linux-aarch64-low.c
+++ b/gdb/gdbserver/linux-aarch64-low.c
@@ -272,39 +272,39 @@ debug_reg_change_callback (struct lwp_info *lwp, void *ptr)
     : &info->dr_changed_bp;
   dr_changed = *dr_changed_ptr;
 
-      gdb_assert (idx >= 0
-		  && (idx <= (is_watchpoint ? aarch64_num_wp_regs
-			      : aarch64_num_bp_regs)));
-
-      /* The following assertion is not right, as there can be changes
-	 that have not been made to the hardware debug registers
-	 before new changes overwrite the old ones.  This can happen,
-	 for instance, when the breakpoint/watchpoint hit one of the
-	 threads and the user enters continue; then what happens is:
-	 1) all breakpoints/watchpoints are removed for all threads;
-	 2) a single step is carried out for the thread that was hit;
-	 3) all of the points are inserted again for all threads;
-	 4) all threads are resumed.
-	 The 2nd step will only affect the one thread in which the
-	 bp/wp was hit, which means only that one thread is resumed;
-	 remember that the actual updating only happen in
-	 aarch64_linux_prepare_to_resume, so other threads remain
-	 stopped during the removal and insertion of bp/wp.  Therefore
-	 for those threads, the change of insertion of the bp/wp
-	 overwrites that of the earlier removals.  (The situation may
-	 be different when bp/wp is steppable, or in the non-stop
-	 mode.)  */
-      /* gdb_assert (DR_N_HAS_CHANGED (dr_changed, idx) == 0);  */
-
-      /* The actual update is done later just before resuming the lwp,
-         we just mark that one register pair needs updating.  */
-      DR_MARK_N_CHANGED (dr_changed, idx);
-      *dr_changed_ptr = dr_changed;
-
-      /* If the lwp isn't stopped, force it to momentarily pause, so
-         we can update its debug registers.  */
-      if (!lwp->stopped)
-	linux_stop_lwp (lwp);
+  gdb_assert (idx >= 0
+	      && (idx <= (is_watchpoint ? aarch64_num_wp_regs
+			  : aarch64_num_bp_regs)));
+
+  /* The following assertion is not right, as there can be changes
+     that have not been made to the hardware debug registers
+     before new changes overwrite the old ones.  This can happen,
+     for instance, when the breakpoint/watchpoint hit one of the
+     threads and the user enters continue; then what happens is:
+     1) all breakpoints/watchpoints are removed for all threads;
+     2) a single step is carried out for the thread that was hit;
+     3) all of the points are inserted again for all threads;
+     4) all threads are resumed.
+     The 2nd step will only affect the one thread in which the
+     bp/wp was hit, which means only that one thread is resumed;
+     remember that the actual updating only happen in
+     aarch64_linux_prepare_to_resume, so other threads remain
+     stopped during the removal and insertion of bp/wp.  Therefore
+     for those threads, the change of insertion of the bp/wp
+     overwrites that of the earlier removals.  (The situation may
+     be different when bp/wp is steppable, or in the non-stop
+     mode.)  */
+  /* gdb_assert (DR_N_HAS_CHANGED (dr_changed, idx) == 0);  */
+
+  /* The actual update is done later just before resuming the lwp,
+     we just mark that one register pair needs updating.  */
+  DR_MARK_N_CHANGED (dr_changed, idx);
+  *dr_changed_ptr = dr_changed;
+
+  /* If the lwp isn't stopped, force it to momentarily pause, so
+     we can update its debug registers.  */
+  if (!lwp->stopped)
+    linux_stop_lwp (lwp);
 
   if (show_debug_regs)
     {
-- 
1.9.1


  parent reply	other threads:[~2015-08-18 15:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-18 15:53 [PATCH 00/13] [aarch64] Share more code between GDB and GDBserver Yao Qi
2015-08-18 15:53 ` [PATCH 01/13] [gdbserver] Use iterate_over_lwps in aarch64_notify_debug_reg_change Yao Qi
2015-08-18 15:53 ` [PATCH 07/13] Make aarch64_notify_debug_reg_change the same on GDB and GDBserver Yao Qi
2015-08-18 15:53 ` [PATCH 11/13] Make aarch64_linux_prepare_to_resume " Yao Qi
2015-08-18 15:53 ` [PATCH 10/13] Add pid argument in aarch64_get_debug_reg_state Yao Qi
2015-08-18 15:53 ` [PATCH 06/13] Use debug_printf in debug_reg_change_callback Yao Qi
2015-08-18 15:53 ` [PATCH 05/13] Use phex debug_reg_change_callback Yao Qi
2015-08-18 15:53 ` [PATCH 04/13] Get pid rather than lwpid Yao Qi
2015-08-25 10:47   ` Pedro Alves
2015-08-25 13:12     ` Yao Qi
2015-08-25 13:33       ` Pedro Alves
2015-08-18 15:53 ` [PATCH 09/13] Move debug_reg_change_callback and aarch64_notify_debug_reg_change to nat/aarch64-linux-hw-point.c Yao Qi
2015-08-18 15:53 ` Yao Qi [this message]
2015-08-18 15:53 ` [PATCH 12/13] Move aarch64_linux_prepare_to_resume to nat/aarch64-linux.c Yao Qi
2015-08-18 15:53 ` [PATCH 13/13] Move aarch64_linux_new_thread " Yao Qi
2015-08-18 15:53 ` [PATCH 03/13] Remove some comments in debug_reg_change_callback Yao Qi
2015-08-18 15:53 ` [PATCH 08/13] Make debug_reg_change_callback the same on GDB and GDBserver Yao Qi
2015-08-25 10:43 ` [PATCH 00/13] [aarch64] Share more code between " Yao Qi

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=1439913199-22882-3-git-send-email-yao.qi@linaro.org \
    --to=qiyaoltc@gmail.com \
    --cc=gdb-patches@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