Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Joos, Christina" <christina.joos@intel.com>
To: Hannes Domani <ssbssa@yahoo.de>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	"Rohr, Stephan" <stephan.rohr@intel.com>
Subject: RE: [PATCH v4 8/9] Windows gdb: Implement AVX-512 register support
Date: Mon, 26 Oct 2026 12:28:14 +0000	[thread overview]
Message-ID: <SN7PR11MB7638B83AB7DF1A8CCC1F6B1489612@SN7PR11MB7638.namprd11.prod.outlook.com> (raw)
In-Reply-To: <1758554357.2910814.1791829980577@mail.yahoo.com>

> -----Original Message-----
> From: Hannes Domani <ssbssa@yahoo.de>
> Sent: Montag, 12. Oktober 2026 20:33
> To: gdb-patches@sourceware.org; Rohr, Stephan <stephan.rohr@intel.com>;
> Joos, Christina <christina.joos@intel.com>
> Subject: Re: [PATCH v4 8/9] Windows gdb: Implement AVX-512 register support
> 
>  Am Montag, 12. Oktober 2026 um 09:59:47 MESZ hat Joos, Christina
> <christina.joos@intel.com> Folgendes geschrieben:
> 
> > Hi Hannes,
> >
> > Thanks for continuing to work on this.
> >
> > > > > Similar to commit 01f9f808e2e86187c95e7cff4aeb014a421a53ce for
> > > > > Linux,
> > > >
> > > > Maybe name the commit title instead of the hash. Not sure what is
> > > > best practice for this.
> > >
> > > This part was suggested to me in another review, so maybe I should
> > > just add both commit hash and title.
> >
> > Showing the commit message is definitely a good idea.
> > My initial review wasn't specific on how exactly you should reference the
> commit, sorry for that.
> > I think this commit is a good example:
> >
> > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=6b369b641c0e
> > feee51356f72d7b317a8906bb8f3
> >
> > I just started looking at this again and have one question upfront:
> > You explained that you ran the dedicated tests for AVX/AVX-512 etc, but has
> this series also been regression-tested?
> 
> Sadly, the testsuite is very unreliable on windows (even though it improved a
> lot recently).
> 
> I now let it first run with current master as baseline:
> 
> # of expected passes 42520
> # of unexpected failures 3334
> # of unexpected successes 1
> # of expected failures 25
> # of known failures 45
> # of untested testcases 133
> # of unresolved testcases 574
> # of unsupported tests 356
> # of paths in test names 32
> # of duplicate test names 60
> 
> Then one time with my AVX changes:
> 
> # of expected passes 41663
> # of unexpected failures 3686
> # of unexpected successes 1
> # of expected failures 26
> # of known failures 45
> # of untested testcases 135
> # of unresolved testcases 565
> # of unsupported tests 355
> # of paths in test names 31
> # of duplicate test names 54
> 
> And again with my changes, so you see what I mean:
> 
> # of expected passes 44348
> # of unexpected failures 2894
> # of unexpected successes 1
> # of expected failures 23
> # of known failures 45
> # of untested testcases 134
> # of unresolved testcases 306
> # of unsupported tests 359
> # of paths in test names 30
> # of duplicate test names 44
> 
> I think it's funny that even the duplicate test names are different each time.
> This was only for gdb.arch/gdb.base/gdb.cp, most of the others wouldn't work
> anyways.
> 
> I can tell you that I first implemented this AVX stuff almost 2 years ago, and had
> no problems using gdb related to it since then.

The GDB testsuite is known to be somewhat flaky:
https://sourceware.org/gdb/wiki/TestingGDB.
However, for linux the requirement is still to do full regressions testing and evaluate
if it's new fails or just flakiness (https://sourceware.org/gdb/wiki/ContributionChecklist).
The situation on Windows is probably a bit different. 

For now, I ran the gdb.arch tests, which I believe are the most relevant ones for this series,
and I did not see any new regressions after applying your patches. Your series clearly improves the situation.
When I continue with gdb.base, I can see that the tests are extremely slow.
I am still waiting for results and am at the same time wondering whether I am doing something wrong.

In any case, I do not think I am the right person to judge whether the regression testing is
sufficiently complete for merging this series.

Also, apologies for the repeated delays. I am currently in a transition/handover phase
before being away for a while (starting middle next week).

Christina



________________________________________
Intel Deutschland GmbH 

Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany 

Tel: +49 (89) 99143-0 

www.intel.de 

Managing Directors: Candice Moore, Jeffrey Schneiderman, Ramachandran Sitaraman

Chairperson of the Supervisory Board: Sonja Pierer

Registered Seat: Munich Commercial Register B: Amtsgericht Munich HRB 186928

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

  reply	other threads:[~2026-10-26 12:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260930151403.774660-1-ssbssa.ref@yahoo.de>
2026-09-30 15:11 ` [PATCH v4 1/9] gdb/testsuite: Add Windows replacement for aligned_alloc Hannes Domani
2026-09-30 15:11   ` [PATCH v4 2/9] Windows gdb: Use allocated buffer for CONTEXT Hannes Domani
2026-09-30 15:11   ` [PATCH v4 3/9] Windows gdb: Remove mappings member from windows_per_inferior Hannes Domani
2026-09-30 15:11   ` [PATCH v4 4/9] Windows gdb: Refactor getting pointer to register inside context Hannes Domani
2026-09-30 15:11   ` [PATCH v4 5/9] Windows gdb: Prepare XState functions Hannes Domani
2026-09-30 15:11   ` [PATCH v4 6/9] Windows gdb: Get available XState features Hannes Domani
2026-09-30 15:11   ` [PATCH v4 7/9] Windows gdb: Implement AVX register support Hannes Domani
2026-10-05 14:09     ` Rohr, Stephan
2026-10-09 14:30       ` Hannes Domani
2026-10-14 13:04         ` Joos, Christina
2026-09-30 15:11   ` [PATCH v4 8/9] Windows gdb: Implement AVX-512 " Hannes Domani
2026-10-05 14:08     ` Rohr, Stephan
2026-10-09 14:36       ` Hannes Domani
2026-10-12  7:59         ` Joos, Christina
2026-10-12 18:33           ` Hannes Domani
2026-10-26 12:28             ` Joos, Christina [this message]
2026-10-14 13:06         ` Joos, Christina
2026-09-30 15:11   ` [PATCH v4 9/9] Windows gdbserver: Remove win32_target_ops "num_regs" method Hannes Domani

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=SN7PR11MB7638B83AB7DF1A8CCC1F6B1489612@SN7PR11MB7638.namprd11.prod.outlook.com \
    --to=christina.joos@intel.com \
    --cc=gdb-patches@sourceware.org \
    --cc=ssbssa@yahoo.de \
    --cc=stephan.rohr@intel.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