Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <xdje42@gmail.com>
To: Pedro Alves <palves@redhat.com>, gdb-patches@sourceware.org
Subject: [PATCH] Don't evaluate condition for non-matching thread
Date: Wed, 13 Nov 2013 03:03:00 -0000	[thread overview]
Message-ID: <m3vbzxovhm.fsf_-_@seba.sebabeach.org> (raw)
In-Reply-To: <5281F6DB.2010603@redhat.com> (Pedro Alves's message of "Tue, 12	Nov 2013 09:37:31 +0000")

Pedro Alves <palves@redhat.com> writes:

> On 11/12/2013 04:05 AM, Doug Evans wrote:
>
>> This patch simplifies bpstat_check_breakpoint_conditions a bit.
>> 
>> Regression tested on amd64-linux.
>> Ok to check in?
>
> Looks good to me.

Thanks.
Next patch.

Is there a reason the current code is the way it is?
Evaluating breakpoint conditions is expensive,
and to do so for a thread-specific breakpoint on a non-matching
thread is an awful waste.
I read the thread-specific breakpoints section of the docs
and didn't find anything.

Regression tested on amd64-linux,
but no claim is made that I'm sure there isn't some gotcha
for why things are the way they are (including "Oops, but it's in the
wild now and reason X means we can't change it." :-)).

Thank goodness the ignore_count check is done after the thread-id check
so there's no change w.r.t. ignore counts.

[I realize conditions can have side-effects, to, e.g., collect data,
but the user has made the breakpoint thread-specific already.]

If you think this warrants a NEWS entry I can certainly add one.

Ok to check in?

2013-11-12  Doug Evans  <xdje42@gmail.com>

	* breakpoint.c (bpstat_check_breakpoint_conditions): For thread
	specific breakpoints, don't evaluate breakpoint condition if
	different thread.

diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index 36252ee..ebb8336 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -5132,6 +5132,14 @@ bpstat_check_breakpoint_conditions (bpstat bs, ptid_t ptid)
       return;
     }
 
+  /* If this is a thread-specific breakpoint, don't waste cpu evaluating the
+     condition if this isn't the specified thread.  */
+  if (b->thread != -1 && b->thread != thread_id)
+    {
+      bs->stop = 0;
+      return;
+    }
+
   /* Evaluate Python breakpoints that have a "stop" method implemented.  */
   if (b->py_bp_object)
     bs->stop = gdbpy_should_stop (b->py_bp_object);
@@ -5215,10 +5223,6 @@ bpstat_check_breakpoint_conditions (bpstat bs, ptid_t ptid)
     {
       bs->stop = 0;
     }
-  else if (b->thread != -1 && b->thread != thread_id)
-    {
-      bs->stop = 0;
-    }
   else if (b->ignore_count > 0)
     {
       b->ignore_count--;


  reply	other threads:[~2013-11-13  3:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-12  7:58 [PATCH] simplify bpstat_check_breakpoint_conditions Doug Evans
2013-11-12  9:54 ` Pedro Alves
2013-11-13  3:03   ` Doug Evans [this message]
2013-11-13  9:59     ` [PATCH] Don't evaluate condition for non-matching thread 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=m3vbzxovhm.fsf_-_@seba.sebabeach.org \
    --to=xdje42@gmail.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