Re: kern/60426 (Signal handler corrupts AVX (YMM) registers)

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60426; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/60426 (Signal handler corrupts AVX (YMM) registers)
Date: Thu, 09 Jul 2026 10:33:14 +0700

     Date:        Wed,  8 Jul 2026 23:48:44 +0000 (UTC)
     From:        riastradh%NetBSD.org@localhost
     Message-ID:  <20260708234844.E01951A923F%mollari.NetBSD.org@localhost>
 
   | But the signal delivery logic, and return-from-signal logic, simply
   | doesn't save and restore anything beyond the xmm registers.
 
 Does it really need to?   There are lots of restrictions on what
 signal handlers are allowed to do, couldn't one of them simply be
 that if these YMM registers are to be touched in the signal handler,
 (or anything it calls) then it becomes the handler's responsibility
 to save and restore them?
 
 Since (as I understand things) not all processors even have the things
 (if running on one old enough) and I think I have seen firmware options
 to disable them as well, I am guessing that the compilers don't just
 emit instructions to use those registers for everyday normal code, and
 that the application needs to do something special to access them.
 In that case, just "don't do that in signal handlers" (just as "don't
 call malloc() in signal handlers, and hence lots other functions which
 might do that", is another of the rules for them).
 
 If the go system wants signal handlers to be able to use AVX stuff, let
 their signal handlers make it work (save/restore whatever state is needed).
 
 A good signal handler often does no more than
 
 	seen_sig_N = 1;
 
 where seen_sig_N is a volatile (global) variable, and then
 returns, leaving it to the normal code (which might have received
 an EINTR from some system call) to check that variable frequently
 enough to behave properly when the signal is received.
 
 Of course, if the signal handler never intends to return, just diagnose
 what happened, and exit, much of this is moot.
 
 kre