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

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

[Hannes Domani]

 Am Mittwoch, 22. Juli 2026 um 17:55:58 MESZ hat Pedro Alves <pedro () palves ! net> Folgendes geschrieben:

> 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?

No, I didn't get this one either.

I did ask about this some time ago on #overseers:

<fche> Apr 30 17:39:57 sourceware postfix/smtp[3802111]: 9DBF1436A055: to=<ssbssa@yahoo.de>, relay=mx-eu.mail.am0.yahoodns.net[188.125.72.74]:25, delay=2.3, delays=0.11/0/0.82/1.4, dsn=5.7.9, status=bounced (host mx-eu.mail.am0.yahoodns.net[188.125.72.74] said: 550 5.7.9 This mail has been blocked because the sender is unauthenticated. Yahoo requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = FAILURE 
<fche> - SPF palves.net with ip X.X.X.X = FAILURE. See https://senders.yahooinc.com/smtp-error-codes/#authentication-failures for more information. (in reply to end of DATA command))
<fche> and yeah yahoo appears to be doing nothing RFC-violating. It just demands DMARC alignment; pedro's domain doesn't DKIM-sign outgoing messages, and without from: rewriting, the sourceware-relayed email's From: still looks like palves.net, which then nukes the DMARC SPF alignment. With neither DKIM nor SPF alignment, DMARC fails.
<mjw> ssbssa, yeah, yahoo.de seems even pickier than other yahoo, but it is generic problem with yahoo in general. They try to do dmarc "alignment" even if the sender doesn't support it. They should fall back to sender spf (which sourceware does set correctly) but don't.


> > 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.

I'll probably have to look into something like this, because it got a lot worse in the last year.


> >>>>>> ---
> >>>>>>   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?

It's not conflicting with the debug-registers bit, so it should be fine.


> >>>> 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.


Thanks
Hannes

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

[Pedro Alves]

On 2026-07-22 17:18, Hannes Domani wrote:
>  Am Mittwoch, 22. Juli 2026 um 17:55:58 MESZ hat Pedro Alves <pedro () palves ! net> Folgendes geschrieben:
> 
>> 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?
> 
> No, I didn't get this one either.
> 
> I did ask about this some time ago on #overseers:
> 
> <fche> Apr 30 17:39:57 sourceware postfix/smtp[3802111]: 9DBF1436A055: to=<ssbssa@yahoo.de>, relay=mx-eu.mail.am0.yahoodns.net[188.125.72.74]:25, delay=2.3, delays=0.11/0/0.82/1.4, dsn=5.7.9, status=bounced (host mx-eu.mail.am0.yahoodns.net[188.125.72.74] said: 550 5.7.9 This mail has been blocked because the sender is unauthenticated. Yahoo requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = FAILURE 
> <fche> - SPF palves.net with ip X.X.X.X = FAILURE. See https://senders.yahooinc.com/smtp-error-codes/#authentication-failures for more information. (in reply to end of DATA command))
> <fche> and yeah yahoo appears to be doing nothing RFC-violating. It just demands DMARC alignment; pedro's domain doesn't DKIM-sign outgoing messages, and without from: rewriting, the sourceware-relayed email's From: still looks like palves.net, which then nukes the DMARC SPF alignment. With neither DKIM nor SPF alignment, DMARC fails.
> <mjw> ssbssa, yeah, yahoo.de seems even pickier than other yahoo, but it is generic problem with yahoo in general. They try to do dmarc "alignment" even if the sender doesn't support it. They should fall back to sender spf (which sourceware does set correctly) but don't.

Thanks, that was very helpful.  I checked my domain and SPF is correct, and DKIM signing is ON.

However, seeing this and my remembering the gmail-in-the-middle thing made the realize what is probably doing on.

And it's simply that I've been using the gmail smtp to send pedro@palves.net emails instead
of the dreamhost (my domain's) smtp, both thunderbird, and git send-email.  That's a gmail feature,
but looks like it breaks SPF/DKIM.

I've since switched to using the dreamhost smtp, and Hannes already confirmed that he is now receiving my
emails, both direct and git send-email ones via the list.

Pedro Alves

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

[Pedro Alves]

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

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

[Hannes Domani]

 Am Mittwoch, 22. Juli 2026 um 14:24:36 MESZ hat Pedro Alves <pedro () palves ! net> Folgendes geschrieben:

> 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.

I wasn't waiting for an Approved-By, but i thought you would have some
comments to my last mail.


> > 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.
Even more so because you recently submitted more windows-related stuff.


> >> 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?

Yes.


> >>>> 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?

Will do.


> >>>> ---
> >>>>  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.


> >> 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?


Hannes

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

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:

>> 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.

Pedro> I'm a little confused, since AFAICT, there has been no patch update to address the
Pedro> comments I made earlier.

When I read the patches I thought your main comment to be addressed was
a typo; with the other comments being questions that Hannes answered in
the negative.

Anyway thank you for this response.

Tom

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

[Pedro Alves]

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

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

[Tom Tromey]

>>>>> "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.

Approved-By: Tom Tromey <tom@tromey.com>

thanks,
Tom

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

[Hannes Domani]

 Ping.


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...
> 
> 
> 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.
> 
> 
> > > 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.
> 
> 
> > > ---
> > >  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)
> 
> 
> > >  struct x86_windows_per_inferior : public windows_per_inferior
> > >  {
> > >    /* The function to use in order to determine whether a register is
> > > @@ -142,7 +146,7 @@ x86_windows_nat_target::thread_context_continue (windows_thread_info *th,
> > >      {
> > >        windows_process->fill_thread_context (th);
> > > 
> > > -      gdb_assert ((context->ContextFlags & CONTEXT_DEBUG_REGISTERS) != 0);
> > > +      gdb_assert ((context->ContextFlags & CONTEXT_DEBUG_REG_FLAG) != 0);
> > > 
> > >        /* Check whether the thread has Dr6 set indicating a
> > >          watchpoint hit, and we haven't seen the watchpoint event
> > > @@ -173,13 +177,13 @@ x86_windows_nat_target::thread_context_continue (windows_thread_info *th,
> > >              update the debug registers later when the thread
> > >              is re-resumed by the core after the watchpoint
> > >              event.  */
> > > -          context->ContextFlags &= ~CONTEXT_DEBUG_REGISTERS;
> > > +          context->ContextFlags &= ~CONTEXT_DEBUG_REG_FLAG;
> > 
> > My bad, I suppose...
> > 
> > Does clearing the arch bit make the context be basically as if it was fully zeroed?
> > 
> > So if we notice we had a pending watchpoint hit, we were not writing _any_ register?
> > 
> > That was not the original intention, for sure.
> > 
> > But OTOH, looking back at this, I'm wondering whether that wasn't really the right thing to do.
> > If we e.g., change the PC to point elsewhere, and then process the pending watchpoint, we'd want
> > to see the PC as it was when the watchpoint triggered, not what it was modified to.  Same for
> > other registers, as the watchpoint's value will very likely depend on the state of registers.
> > 
> > Right?
> > 
> > OTOH, if e.g., the user did an infcall on a thread that has a pending watchpoint, and we don't
> > modify registers, and then the watchpoint doesn't cause a stop, not writing registers means
> > we'll not really do the infcall, and the inferior proceeds as if we had done a "continue"...
> > Not great either.
> > 
> > OK, let's just do what you're suggesting until we come up with a better way, as it was the
> > original intention.  I'm just curious for more details.
> 
> 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.
> 
> 
> Hannes

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

[Hannes Domani]

 It's just great that all your mails are blocked by yahoo...


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.


> > 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.


> > ---
> >  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)


> >  struct x86_windows_per_inferior : public windows_per_inferior
> >  {
> >    /* The function to use in order to determine whether a register is
> > @@ -142,7 +146,7 @@ x86_windows_nat_target::thread_context_continue (windows_thread_info *th,
> >      {
> >        windows_process->fill_thread_context (th);
> > 
> > -      gdb_assert ((context->ContextFlags & CONTEXT_DEBUG_REGISTERS) != 0);
> > +      gdb_assert ((context->ContextFlags & CONTEXT_DEBUG_REG_FLAG) != 0);
> > 
> >        /* Check whether the thread has Dr6 set indicating a
> >          watchpoint hit, and we haven't seen the watchpoint event
> > @@ -173,13 +177,13 @@ x86_windows_nat_target::thread_context_continue (windows_thread_info *th,
> >              update the debug registers later when the thread
> >              is re-resumed by the core after the watchpoint
> >              event.  */
> > -          context->ContextFlags &= ~CONTEXT_DEBUG_REGISTERS;
> > +          context->ContextFlags &= ~CONTEXT_DEBUG_REG_FLAG;
> 
> My bad, I suppose...
> 
> Does clearing the arch bit make the context be basically as if it was fully zeroed?
> 
> So if we notice we had a pending watchpoint hit, we were not writing _any_ register?
> 
> That was not the original intention, for sure.
> 
> But OTOH, looking back at this, I'm wondering whether that wasn't really the right thing to do.
> If we e.g., change the PC to point elsewhere, and then process the pending watchpoint, we'd want
> to see the PC as it was when the watchpoint triggered, not what it was modified to.  Same for
> other registers, as the watchpoint's value will very likely depend on the state of registers.
> 
> Right?
> 
> OTOH, if e.g., the user did an infcall on a thread that has a pending watchpoint, and we don't
> modify registers, and then the watchpoint doesn't cause a stop, not writing registers means
> we'll not really do the infcall, and the inferior proceeds as if we had done a "continue"...
> Not great either.
> 
> OK, let's just do what you're suggesting until we come up with a better way, as it was the
> original intention.  I'm just curious for more details.

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.


Hannes

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

[Pedro Alves]

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

> 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.


> ---
>  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)



>  struct x86_windows_per_inferior : public windows_per_inferior
>  {
>    /* The function to use in order to determine whether a register is
> @@ -142,7 +146,7 @@ x86_windows_nat_target::thread_context_continue (windows_thread_info *th,
>  	{
>  	  windows_process->fill_thread_context (th);
>  
> -	  gdb_assert ((context->ContextFlags & CONTEXT_DEBUG_REGISTERS) != 0);
> +	  gdb_assert ((context->ContextFlags & CONTEXT_DEBUG_REG_FLAG) != 0);
>  
>  	  /* Check whether the thread has Dr6 set indicating a
>  	     watchpoint hit, and we haven't seen the watchpoint event
> @@ -173,13 +177,13 @@ x86_windows_nat_target::thread_context_continue (windows_thread_info *th,
>  		     update the debug registers later when the thread
>  		     is re-resumed by the core after the watchpoint
>  		     event.  */
> -		  context->ContextFlags &= ~CONTEXT_DEBUG_REGISTERS;
> +		  context->ContextFlags &= ~CONTEXT_DEBUG_REG_FLAG;

My bad, I suppose...

Does clearing the arch bit make the context be basically as if it was fully zeroed?

So if we notice we had a pending watchpoint hit, we were not writing _any_ register?

That was not the original intention, for sure. 

But OTOH, looking back at this, I'm wondering whether that wasn't really the right thing to do.
If we e.g., change the PC to point elsewhere, and then process the pending watchpoint, we'd want
to see the PC as it was when the watchpoint triggered, not what it was modified to.  Same for
other registers, as the watchpoint's value will very likely depend on the state of registers.

Right?

OTOH, if e.g., the user did an infcall on a thread that has a pending watchpoint, and we don't
modify registers, and then the watchpoint doesn't cause a stop, not writing registers means
we'll not really do the infcall, and the inferior proceeds as if we had done a "continue"...
Not great either.

OK, let's just do what you're suggesting until we come up with a better way, as it was the
original intention.  I'm just curious for more details.

Pedro Alves

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

[Hannes Domani]

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
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.
---
 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
+
 struct x86_windows_per_inferior : public windows_per_inferior
 {
   /* The function to use in order to determine whether a register is
@@ -142,7 +146,7 @@ x86_windows_nat_target::thread_context_continue (windows_thread_info *th,
 	{
 	  windows_process->fill_thread_context (th);
 
-	  gdb_assert ((context->ContextFlags & CONTEXT_DEBUG_REGISTERS) != 0);
+	  gdb_assert ((context->ContextFlags & CONTEXT_DEBUG_REG_FLAG) != 0);
 
 	  /* Check whether the thread has Dr6 set indicating a
 	     watchpoint hit, and we haven't seen the watchpoint event
@@ -173,13 +177,13 @@ x86_windows_nat_target::thread_context_continue (windows_thread_info *th,
 		     update the debug registers later when the thread
 		     is re-resumed by the core after the watchpoint
 		     event.  */
-		  context->ContextFlags &= ~CONTEXT_DEBUG_REGISTERS;
+		  context->ContextFlags &= ~CONTEXT_DEBUG_REG_FLAG;
 		}
 	    }
 	  else
 	    DEBUG_EVENTS ("0x%x has no dr6 set", th->tid);
 
-	  if ((context->ContextFlags & CONTEXT_DEBUG_REGISTERS) != 0)
+	  if ((context->ContextFlags & CONTEXT_DEBUG_REG_FLAG) != 0)
 	    {
 	      DEBUG_EVENTS ("0x%x changing dregs", th->tid);
 	      context->Dr0 = state->dr_mirror[0];
-- 
2.54.0