Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@ericsson.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH 2/3] gdbserver lwp_info: Initialize fields, use new/delete
Date: Tue, 25 Jul 2017 10:19:00 -0000	[thread overview]
Message-ID: <872a159d-95a0-f2e1-6100-24d681ff348e@ericsson.com> (raw)
In-Reply-To: <861sp4rg6i.fsf@gmail.com>

On 2017-07-25 11:58 AM, Yao Qi wrote:
> Simon Marchi <simon.marchi@ericsson.com> writes:
> 
>> @@ -3480,7 +3476,7 @@ linux_wait_1 (ptid_t ptid,
>>        event_child->collecting_fast_tracepoint
>>  	= linux_fast_tracepoint_collecting (event_child, NULL);
>>  
>> -      if (event_child->collecting_fast_tracepoint != 1)
>> +      if (!event_child->collecting_fast_tracepoint)
>>  	{
>>  	  /* No longer need this breakpoint.  */
>>  	  if (event_child->exit_jump_pad_bkpt != NULL)
> 
> linux_fast_tracepoint_collecting doesn't return boolean, it returns 0, 1
> and 2.   See comments in tracepoint.c:fast_tracepoint_collecting.

Oh, thanks for noticing this!  I think I've been misguided be the comment on
linux_fast_tracepoint_collecting that says "true":

/* Convenience wrapper.  Returns true if LWP is presently collecting a
   fast tracepoint.  */

static int
linux_fast_tracepoint_collecting (struct lwp_info *lwp,
				  struct fast_tpoint_collect_status *status)

Maybe we should make it return an enum so it's clear, because the function name
really sounds like it would return a bool.


Here's the a fixup to this patch that restores the original code:

From 61b9c0b842ef8ecddd0ef8a1be12676d6f9e61ba Mon Sep 17 00:00:00 2001
From: Simon Marchi <simon.marchi@ericsson.com>
Date: Tue, 25 Jul 2017 12:15:33 +0200
Subject: [PATCH] fixup fast_tracepoint_collecting does not return bool

---
 gdb/gdbserver/linux-low.c | 8 ++++----
 gdb/gdbserver/linux-low.h | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c
index e650b0d..ab3e860 100644
--- a/gdb/gdbserver/linux-low.c
+++ b/gdb/gdbserver/linux-low.c
@@ -2177,7 +2177,7 @@ maybe_move_out_of_jump_pad (struct lwp_info *lwp, int *wstat)
 	     reporting to GDB.  Otherwise, it's an IPA lib bug: just
 	     report the signal to GDB, and pray for the best.  */

-	  lwp->collecting_fast_tracepoint = false;
+	  lwp->collecting_fast_tracepoint = 0;

 	  if (r != 0
 	      && (status.adjusted_insn_addr <= lwp->stop_pc
@@ -3476,7 +3476,7 @@ linux_wait_1 (ptid_t ptid,
       event_child->collecting_fast_tracepoint
 	= linux_fast_tracepoint_collecting (event_child, NULL);

-      if (!event_child->collecting_fast_tracepoint)
+      if (event_child->collecting_fast_tracepoint != 1)
 	{
 	  /* No longer need this breakpoint.  */
 	  if (event_child->exit_jump_pad_bkpt != NULL)
@@ -3503,7 +3503,7 @@ linux_wait_1 (ptid_t ptid,
 	    }
 	}

-      if (!event_child->collecting_fast_tracepoint)
+      if (event_child->collecting_fast_tracepoint == 0)
 	{
 	  if (debug_threads)
 	    debug_printf ("fast tracepoint finished "
@@ -5290,7 +5290,7 @@ proceed_one_lwp (struct inferior_list_entry *entry, void *except)

   if (thread->last_resume_kind == resume_stop
       && lwp->pending_signals_to_report == NULL
-      && !lwp->collecting_fast_tracepoint)
+      && lwp->collecting_fast_tracepoint == 0)
     {
       /* We haven't reported this LWP as stopped yet (otherwise, the
 	 last_status.kind check above would catch it, and we wouldn't
diff --git a/gdb/gdbserver/linux-low.h b/gdb/gdbserver/linux-low.h
index dcc9315..f93aefb 100644
--- a/gdb/gdbserver/linux-low.h
+++ b/gdb/gdbserver/linux-low.h
@@ -358,7 +358,7 @@ struct lwp_info
      return to the jump pad.  Normally, we won't care about this, but
      we will if a signal arrives to this lwp while it is
      collecting.  */
-  bool collecting_fast_tracepoint = false;
+  int collecting_fast_tracepoint = 0;

   /* If this is non-zero, it points to a chain of signals which need
      to be reported to GDB.  These were deferred because the thread
-- 
2.7.4


  reply	other threads:[~2017-07-25 10:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-24 10:40 [PATCH 0/3] Create arch_lwp_info class hierarchy Simon Marchi
2017-07-24 10:40 ` [PATCH 3/3] " Simon Marchi
2017-08-09 20:47   ` Simon Marchi
2017-07-24 10:40 ` [PATCH 1/3] gdb lwp_info: Add destructor, initialize fields, use new/delete Simon Marchi
2017-07-24 10:43   ` Simon Marchi
2017-07-25  9:39   ` Yao Qi
2017-07-24 10:40 ` [PATCH 2/3] gdbserver lwp_info: Initialize " Simon Marchi
2017-07-25  9:58   ` Yao Qi
2017-07-25 10:19     ` Simon Marchi [this message]
2017-07-25 15:25       ` Yao Qi
2017-08-11 20:13 ` [PATCH 0/3] Create arch_lwp_info class hierarchy Pedro Alves
2017-08-12 11:31   ` Simon Marchi
2017-08-14 11:53     ` Pedro Alves
2017-08-16 18:44       ` Simon Marchi
2017-08-18 11:23         ` 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=872a159d-95a0-f2e1-6100-24d681ff348e@ericsson.com \
    --to=simon.marchi@ericsson.com \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@gmail.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