Well, avoiding XMM registers in duffcopy/duffzero is one solution, but I was thinking of working around them entirely in code called from the note handler, so that duffcopy/duffzero can operate as intended on plan9, rather than littering the compiler with OS conditionals.
It puts some restrictions on the note handling code, such as no copy(), make() or even an on-stack var b [n]byte. Due to sighandler disabling write barriers, we can't currently allocate on the heap, meaning that we might need either locked global buffers (which can be duffzeroed) or more assembly so we can use on-stack buffers (which could be zeroed if we wanted to, they just can't use duffzero for it). To fix the duffzero, we'd have to fix runtime.goexitsall's buffer usage, but to reenable duffcopy, we'd have to look at the much bigger runtime.sighandler. Best regards, Kenny Levinsen On 23. feb. 2016, at 08.20, lu...@proxima.alt.za wrote: >> Duffcopy is disabled from plan9 after the last bug report on the >> matter, but duffzero was later optimized to use XMM registers, causing >> goexitsall, which use an on-stack byte array to make a new note, to >> call duffzero and trip the fp in note handler message. > > I had to re-read this to understand this because you tend to put at > the end what I would find easier to understand if it was at the > beginning. No offence meant, different punctuation would have perhaps > helped my understanding. > > So, we need a duffcopy and duffzero that do not use XMM registers, > rather than stop invoking them, if I read your comment correctly? > > I also have an open issue (I see David has offered to look into it > soon) involving syscalls and their error messages, it seems these are > all Plan 9 specific issues that could be addressed together. > > I really would like to take a more active role in Go for Plan 9, but I > can't yet give it the priority I'd like. Still, I like hearing from > others who take this to heart. > > Lucio. >
