Hello, The haskell packages builds have shown that we still have unexpected xmm clobbers on signals/interrupt or such on x86_64.
This can be seen notably with package haskell-src-exts: https://buildd.debian.org/status/logs.php?pkg=haskell-src-exts&arch=hurd-amd64 we have more than two dozen failures trying to build it, giving waitForProcess: failed ((ipc/mig) server type check failure) That's with libc0.3_2.42-8~hurd.1, and as soon as I updated to libc0.3_2.42-8~hurd.2, it built fine. The only difference between these two libcs is Index: glibc-2.38/hurd/intr-msg.c =================================================================== --- glibc-2.38.orig/hurd/intr-msg.c +++ glibc-2.38/hurd/intr-msg.c @@ -79,7 +79,7 @@ _hurd_intr_rpc_mach_msg (mach_msg_header mach_msg_bits_t msgh_bits; mach_port_t remote_port; mach_msg_id_t msgid; - struct clobber save_data; + volatile struct clobber save_data; if ((option & (MACH_SEND_MSG|MACH_RCV_MSG)) != (MACH_SEND_MSG|MACH_RCV_MSG) || _hurd_msgport_thread == MACH_PORT_NULL) which makes sure to put the content of save_data on the stack instead of in xmm0, while calling mach_msg(). So we have something that clobbers xmm0 somehow, and this is only a dumb workaround that only avoids the issue in the notable but still particular case of blocking RPCs. We do have a basic test against signals, hurd/test-sig-xstate.c, but apparently it's not stressful enough. haskell is a bit particular compared to other packages because it has a preemption SIGVTALRM signal happening periodically, which is most probably the trigger for the issue. Notably, during the ghc package build, I have to use GHCRTS=-V0 to disable it, otherwise I'm seeing corruptions. The haskell packages builds occasionally see such corruptions too. Samuel
