From mboxrd@z Thu Jan  1 00:00:00 1970
References: <83031ee52a34de15facd95dcbcabbad9@proxima.alt.za>
Mime-Version: 1.0 (1.0)
In-Reply-To: <83031ee52a34de15facd95dcbcabbad9@proxima.alt.za>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <93ADCA66-EE37-44E9-BD39-72DE7E5119F6@gmail.com>
From: Kenny Lasse Hoff Levinsen <kennylevinsen@gmail.com>
Date: Tue, 23 Feb 2016 09:26:21 +0100
To: 9fans@9fans.net
Cc: lucio@proxima.alt.za
Subject: Re: [9fans] Go: FP in note handler
Topicbox-Message-UUID: 88a9d480-ead9-11e9-9d60-3106f5b1d025

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 handl=
er, so that duffcopy/duffzero can operate as intended on plan9, rather than l=
ittering 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 barr=
iers, we can't currently allocate on the heap, meaning that we might need ei=
ther locked global buffers (which can be duffzeroed) or more assembly so we c=
an use on-stack buffers (which could be zeroed if we wanted to, they just ca=
n'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.sighandl=
er.

Best regards,
Kenny Levinsen

On 23. feb. 2016, at 08.20, lucio@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.
>=20
> 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.
>=20
> So, we need a duffcopy and duffzero that do not use XMM registers,
> rather than stop invoking them, if I read your comment correctly?
>=20
> 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.
>=20
> 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.
>=20
> Lucio.
>=20