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

 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 <[email protected]> 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=<[email protected]>, 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