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--;
next prev parent 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