Re: [9fans] Plan 9 Go 386

[lucio@proxima.alt.za]

I've seen this before, although by now I've seen so many errors crop
up that I can't recall them all.

>> === RUN TestErrors-2
>> template.test 289408: suicide: sys: floating point in note handler pc=0x0001e9c7
>> exit status: 'template.test 289408: sys: floating point in note
>> handler pc=0x0001e9c7'
>> FAIL html/template 0.213s
>
> acid: stk()
> runtime.memmove(to=0x106dd000,fr=0x30887660,n=0x2c)+0x107
> /usr/glenda/src/go/src/pkg/runtime/memmove_386.s:145
> runtime.sighandler(s=0x30887660,v=0x308876e4,gp=0x106d31b0)+0x126
> /usr/glenda/src/go/src/pkg/runtime/os_plan9_386.c:67
> runtime.sigtramp(ureg=0x30887660,note=0x106d31b0)+0x44
> /usr/glenda/src/go/src/pkg/runtime/sys_plan9_386.s:161
> 0x308876e4 ?file?:0
> acid:

I am surprised, but also relieved that we have a resproducible mistake
outside the run.rc scope.  We can focus on that.

I'm hoping cinap, with his in-depth knowledge of the kernel, can shed
some light here.  It does look as if we have some error in the
handling of syscalls or notes, although I already mentioned I expected
a note to a process that had received a floating point exception
rather than a floating point exception in a note handler.

In my most recent copy of src/go/src/pkg/runtime/sys_plan9_386.s line
161 is a get_tls(BX), on return from sighandler().  Get_tls on the 386
resolves to

	MOVL _tos(SB),r // zasm_plan9_386.h:8

so unless SB is way off, it does not seem to be a problem.  I'd lay my
bets on sighandler() (so_plan9_386.c:28), but I am not comfortable
digging in there.

++L