What I thought was a floating-point problem turned out to be an integer problem: noted(NCONT) was smashing a few of the integer registers on its way back to the original note context. Nothing to do with floats at all. https://github.com/rsc/plan9/commit/aa00f938f6b3c6a5b4502c25605666f479a22c16
On Mon, Mar 3, 2025 at 11:17 AM <cinap_len...@felloff.net> wrote: > one issue i can see with this is that now it is unclear what > /proc/$pid/fpregs is supposed to be once a process executes > the note handler. > I was focusing on making something work at all, but I agree that's a detail to get right. I believe that /proc/$pid/regs is the note registers during the note handler, and so .../fpregs should be the same. I don't think we need fpregs and ofpregs, since we don't have regs and oregs. also, do we want the note-handler to have a clean (FPinit) fpu > context or should it get a copy? and why? > I chose to give it a copy because systems might initialize certain registers to certain values at startup and then assume those are always set. Copying preserves those decisions. The integer registers are also copied. To me it fits with the simple elegance of fork compared to the awkwardness of StartProcess. (Other operating system designers may disagree, but Plan 9 is a system in the fork camp.) > do we want to backport this to all architectures, or just > the ones that combine fp and vector instructions? > It would make sense to me to allow on all architectures for consistency, but I'm personally working on this as a Go developer, not a Plan 9 developer. I'm just trying to minimize the irregularities that Go takes on to support Plan 9. Thanks for looking into making the same fix on 9front. I think my /sys/src/9k fix is a little cleaner, for what it's worth. In the /sys/src/9 fix I probably should have used two state fields instead of one shifty field. it would be a good idea to document this changes of behaviour > somewhere and have a rationale. > Definitely. My tree is a personal work space, not a real Plan 9 distribution. I don't think you need much rationale though. This was an irregular limitation that has been removed. Vector instructions have become very important and will only become more so. Plan 9 couldn't even use them in memmove because memmove might be called in a note handler. To me at least, that's clearly wrong. The limitation was bearable only because it didn't matter much. Now it matters a significant amount. I notice that the 9front kernel allows floating point during kernel execution, presumably for the same reason. Updated the docs in my tree: https://github.com/rsc/plan9/commit/dd95b25897369ff2575b2ad744e18954c4620464 and last: have the go developers considered alternatives > such as NSAVE/NRSTR for their "signal" handling? > I've never worked on the Plan 9 port of Go before, so I can't speak for the port's developers did, but I had completely forgotten NSAVE/NRSTR existed. I just looked at them anew, and I don't think they would help. noted(NRSTR) puts the onus of saving registers on the user process, which is maybe not great but fine for the CPU registers in the ureg struct, but the FPU registers aren't there. You'd need to make a separate space for them, and then worry about all the nuances of different FP save routines on different systems, detecting whether they need to be saved at all, and so on. The kernel already has to get all that code right for context switches. Getting it right for note handlers seems like a reasonably small expansion of that role. Other operating systems do that just fine. And as I noted (ha!) earlier, this change benefits C as much as it benefits Go. Best, Russ ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Taf6b900592afc500-Mb1f1ebaf3409dab87046da32 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
