From: Paolo Bonzini <pbonzini@redhat.com>
To: Richard Henderson <rth@twiddle.net>, qemu-devel@nongnu.org
Cc: ehabkost@redhat.com
Subject: Re: [Qemu-devel] [PATCH 4/8] target-i386: Re-introduce optimal breakpoint removal
Date: Wed, 16 Sep 2015 16:59:48 +0200 [thread overview]
Message-ID: <55F983E4.6050107@redhat.com> (raw)
In-Reply-To: <55F98340.1040801@twiddle.net>
On 16/09/2015 16:57, Richard Henderson wrote:
>>> >> + /* Fold the global and local enable bits together into the
>>> >> + global fields, then xor to show which registers have
>>> >> + changed collective enable state. */
>>> >> + int mod = ((old_dr7 | old_dr7 * 2) ^ (new_dr7 | new_dr7 * 2)) & 0xff;
>> >
>> > The AND is not needed at all but, if you add it, you might as well use
>> > "& 0xaa" which is clearer. But even better, just do:
>> >
>> > target_ulong old_dr7 = env->dr[7];
>> > int mod = old_dr7 ^ new_dr7;
>> > ...
>> > if ((mod & ~0xff) == 0) {
>> >
>> >
>> > and test with
>> >
>> > if (mod & (3 << i * 2))
>> >
>> > inside the loop.
> Nope. I wrote that the first time myself. We're interested in two different
> things: (1) whether or not something changed outside enable bits, and (2)
> whether the enable state changed.
>
> Since (2) is a combination of both global and local enable bits, we must
> combine them *and then xor* to see if the enable state actually changes. Just
> using (mod & (3 << n)) will report "change" when local enable turns off, but
> global enable remains on. Which is not what we want.
Ah, I see now. Perhaps
int old_enable = (old_dr7 | (old_dr7 << 1)) & 0xaa;
int new_enable = (new_dr7 | (new_dr7 << 1)) & 0xaa;
?
> Perhaps that comment could stand to be expanded...
I think at least for me it's just the expression that is too complex.
Paolo
next prev parent reply other threads:[~2015-09-16 15:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-15 18:45 [Qemu-devel] [PATCH 0/8] target-i386: Implement debug extensions Richard Henderson
2015-09-15 18:45 ` [Qemu-devel] [PATCH 1/8] target-i386: Move breakpoint related functions to new file Richard Henderson
2015-09-18 18:27 ` Eduardo Habkost
2015-09-15 18:45 ` [Qemu-devel] [PATCH 2/8] target-i386: Make check_hw_breakpoints static Richard Henderson
2015-09-18 18:29 ` Eduardo Habkost
2015-09-15 18:45 ` [Qemu-devel] [PATCH 3/8] target-i386: Introduce cpu_x86_update_dr7 Richard Henderson
2015-09-15 18:45 ` [Qemu-devel] [PATCH 4/8] target-i386: Re-introduce optimal breakpoint removal Richard Henderson
2015-09-16 8:57 ` Paolo Bonzini
2015-09-16 14:57 ` Richard Henderson
2015-09-16 14:59 ` Paolo Bonzini [this message]
2015-09-18 18:38 ` Eduardo Habkost
2015-09-15 18:45 ` [Qemu-devel] [PATCH 5/8] target-i386: Move hw_*breakpoint_* functions Richard Henderson
2015-09-15 18:45 ` [Qemu-devel] [PATCH 6/8] target-i386: Optimize setting dr[0-3] Richard Henderson
2015-09-15 18:45 ` [Qemu-devel] [PATCH 7/8] target-i386: Handle I/O breakpoints Richard Henderson
2015-09-15 18:45 ` [Qemu-devel] [PATCH 8/8] target-i386: Check CR4[DE] for processing DR4/DR5 Richard Henderson
2015-09-21 12:05 ` [Qemu-devel] [PATCH 0/8] target-i386: Implement debug extensions Paolo Bonzini
2015-09-21 14:05 ` Eduardo Habkost
2015-09-21 14:11 ` Paolo Bonzini
2015-09-28 18:26 ` Eduardo Habkost
2015-09-28 18:48 ` Eduardo Habkost
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=55F983E4.6050107@redhat.com \
--to=pbonzini@redhat.com \
--cc=ehabkost@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.