cherrymui
cherrymui
Sorry, I was OOO and then was occupied when I was back. My plan is to get a new version of [CL 600296](https://go.dev/cl/600296) that covers both this and #68285. I'll...
I updated [CL 600296](https://go.dev/cl/600296) to cover this, implemented basically [https://github.com/golang/go/issues/68587#issuecomment-2304877746](https://github.com/golang/go/issues/68587#issuecomment-2304877746). If the stack moved, we use a new bounds of [SP, SP+32KB), which I think is not that different from...
cc @bradfitz @kardianos @kevinburke
The runtime doesn't async preempt assembly functions. asyncPreempt (the function in runtime/preempt_amd64.s) should not be executed if it is running in an assembly function. The runtime sends a signal, but...
> It is quite possible that this issue I'm seeing is new with golang 1.17. Is it possible that the new assembly adapter funcs required for inter-operation with the new...
@vsivsi thanks for the repro! So it seems it is not related preemption but signals in general. The observation about K0-K7 also suggests VZEROUPPER is not the cause. Would it...
Thanks for trying that. In your C code, could you install a signal handler for SIGURG (which could simply return immediately)? Thanks.
Thanks @vsivsi ! That indicates the kernel's signal handling code doesn't seem to do the right thing.
If there is a simple workaround that we could do it in the runtime, we'll do it, like the VZEROUPPER for #37174 . I don't know how to work around...
As it is not safe to use, maybe we could consider hardwire AVX512 to false on Darwin until the kernel fix?