Re: [PATCH] Windows gdb: Fix resetting of the debug-registers bit in ContextFlags

[Pedro Alves <pedro@palves.net>]

On 2026-07-22 15:55, Hannes Domani wrote:

>>> 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.
> 
> I know, it's just very frustrating.

Is this only about emails sent to the mailing list, i.e., ones that are sent to you by sourceware's Mailman,
not me directly?  Do you receive the direct copy when I To: you directly, like this one?

> Even more so because you recently submitted more windows-related stuff.

FWIW, I subscribe to the mailing list using my gmail account, but nobody ever sees that, because
I always respond with my palves.net email address.  I use Thunderbird, and there the "Correct Identify"
add-on is super useful for this -- I have it set up to that when I reply to an email from the sourceware
domain that I received on the gmail inbox, the thunderbird email writing windows automatically pops with with
my palves.net address as the default sender.

In a nutshell, I freeload on gmail as my public mailing list storage.  It's all archived public messages,
so I'm fine with that.  :-)

If this is only about the mailing list emails, maybe a setup like that would work for you, too.


> 
>>>>>> ---
>>>>>>   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 didn't really have a good reason, so I'll do it like this in v2.

Hmm, I hadn't looked at CONTEXT_CONTROL's definition before.  I did now:

 #define CONTEXT_AMD64 0x100000
 #define CONTEXT_CONTROL (CONTEXT_AMD64 | __MSABI_LONG(0x1))

So it's more then the arch bit?  Is that really correct to use here?

> 
> 
>>>> 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.
> 
> This was also a point where I thought you would give some comment, I
> was wrong about that too.
> 
> So, when in doubt, I should send an updated patch?
> 

I'm not sure we can come up with a rule.  :-)  I guess what I missed is a question
instead of a statement.  I'll try to avoid assuming as much too.

Cheers,
Pedro Alves