From: Pedro Alves <pedro@palves.net>
To: Tom Tromey <tom@tromey.com>, Hannes Domani <ssbssa@yahoo.de>
Cc: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Windows gdb: Fix resetting of the debug-registers bit in ContextFlags
Date: Wed, 22 Jul 2026 13:24:36 +0100 [thread overview]
Message-ID: <1ce9ef92-cf15-4dec-b310-2a0140a828da@palves.net> (raw)
In-Reply-To: <874ihswakf.fsf@tromey.com>
On 2026-07-21 17:51, Tom Tromey wrote:
>>>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes:
>
> Hannes> Ping.
>
> I'd prefer Pedro reply, but FWIW I think the patch looks reasonable.
> You can have my approval but please wait a bit to see if Pedro has some
> other comments.
I'm a little confused, since AFAICT, there has been no patch update to address the
comments I made earlier.
We've established that the patch isn't really "fixing" the resetting of registers, as the
missing context flag is ignored anyway. So at the very least I was expecting that the subject and commit
log would be updated to match reality.
> Am Montag, 6. Juli 2026 um 17:02:35 MESZ hat Hannes Domani <ssbssa@yahoo.de> Folgendes geschrieben:
>
>> It's just great that all your mails are blocked by yahoo...
Sorry, but I don't know what I can do about that. My hosting provider, including email is dreamhost,
which is quite popular and I believe used by others in the community too. I don't have anything special
going on with my email AFAIK.
>>
>>
>> Am Mittwoch, 1. Juli 2026 um 21:03:09 MESZ hat Pedro Alves <pedro () palves ! net> Folgendes geschrieben:
>>
>>> On 2026-06-27 15:27, Hannes Domani wrote:
>>>> The CONTEXT_DEBUG_REGISTERS also includes the arch-specific bit
>>>> (CONTEXT_i386 or CONTEXT_AMD64) which is included in all CONTEXT_*
>>>> defines.
>>>>
>>>> So this basically just checks if any CONTEXT_* define is set:
>>>> if ((context->ContextFlags & CONTEXT_DEBUG_REGISTERS) != 0)
>>>>
>>>> And similarily, unsetting CONTEXT_DEBUG_REGISTERS removes the
>>>
>>> similarily => similarly
>>
>> Right.
Can you fix?
>>
>>
>>>> arch-specific bit as well.
>>>>
>>>> So this creates a CONTEXT_DEBUG_REG_FLAG define with just the
>>>> debug-registers bit, and uses it in these problematic locations.
>>>
>>> How did you notice this? Like, GDB was misbehaving and you found the
>>> issue, was it by inspection? I'd be good to have that info in the commit log.
>>
>> I noticed because I was doing some changes in that function, and
>> CONTEXT_DEBUG_REGISTERS stood out to me very quickly, because for WOW64 I
>> would expect WindowsContext<decltype(context)>::debug to be used instead.
OK. Can you please add this to the commit log? That does seem like something
we need to fix, and should be rationale for the change, right?
>>
>>
>>>> ---
>>>> gdb/x86-windows-nat.c | 10 +++++++---
>>>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/gdb/x86-windows-nat.c b/gdb/x86-windows-nat.c
>>>> index 27adeb1f154..3368814ed96 100644
>>>> --- a/gdb/x86-windows-nat.c
>>>> +++ b/gdb/x86-windows-nat.c
>>>> @@ -42,6 +42,10 @@ enum
>>>>
>>>> #define DR6_CLEAR_VALUE 0xffff0ff0
>>>
>>>>
>>>> +/* The CONTEXT_DEBUG_REGISTERS define without the arch-specific bit
>>>> + (CONTEXT_i386 or CONTEXT_AMD64). */
>>>> +#define CONTEXT_DEBUG_REG_FLAG 0x10
>>>> +
>>>
>>> Did you consider avoiding harcoding numbers, like:
>>>
>>> #ifdef __x86_64__
>>> # define CONTEXT_ARCH_BIT CONTEXT_AMD64
>>> #else
>>> # define CONTEXT_ARCH_BIT CONTEXT_i386
>>> #endif
>>>
>>> #define CONTEXT_DEBUG_REG_FLAG (CONTEXT_DEBUG_REGISTERS & ~CONTEXT_ARCH_BIT)
>>
>> I did consider this:
>>
>> #define CONTEXT_DEBUG_REG_FLAG (CONTEXT_DEBUG_REGISTERS & ~CONTEXT_CONTROL)
OK, so why did you decide against it?
>> I did some experiments, and it looks like SetThreadContext doesn't care at
>> all about the arch bit, so it is working like your original intention.
>> I thought it would fail in the arch bit is missing, but I was wrong about that.
>>
Seeing this, FYI, I didn't know if you planed on dropping the patch, or sending an
updated one with a commit log that reflects the finding. But I didn't think the
current one as it was, was ready.
Pedro Alves
next prev parent reply other threads:[~2026-07-22 12:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <96f2bcf2-96e5-46ea-9931-c9203415a9df () palves ! net>
2026-07-06 15:01 ` Hannes Domani
2026-07-21 15:02 ` Hannes Domani
2026-07-21 16:51 ` Tom Tromey
2026-07-22 12:24 ` Pedro Alves [this message]
2026-07-22 13:40 ` Tom Tromey
[not found] <1310341683.1974283.1784737131422.ref@mail.yahoo.com>
2026-07-22 16:18 ` Hannes Domani
2026-07-23 19:04 ` Pedro Alves
[not found] <590795675.1923429.1784732125709.ref@mail.yahoo.com>
2026-07-22 14:55 ` Hannes Domani
2026-07-22 15:55 ` Pedro Alves
[not found] <20260627142740.3995235-1-ssbssa.ref@yahoo.de>
2026-06-27 14:27 ` Hannes Domani
2026-07-01 19:03 ` 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=1ce9ef92-cf15-4dec-b310-2a0140a828da@palves.net \
--to=pedro@palves.net \
--cc=gdb-patches@sourceware.org \
--cc=ssbssa@yahoo.de \
--cc=tom@tromey.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