Re: [9fans] sysrfork fp bug?

[erik quanstrom <quanstro@quanstro.net>]

	/* don't penalize the child, it hasn't done FP in a note handler. */
	p->fpstate = up->fpstate & ~FPillegal;
[...]
	ready(p);
	sched();
	return pid;

we do know that fp->state is FPinactive (because of rfork), but it seems
like this isn't doing what was intended, and if there are any values on the
x87 stack, they could well ... stack, which could lead to eventual fp stack
overflow.

given this discussion, and some prior cleanup i'm currently using this
incantation called from sysrfork in the pc arch dependent code.
fp is a FPArch* to accomidate sse or x87.  it's a little gross, but i did
need some sse instructions at one point on a 386 kernel.  eventually
the x87 stuff should be killed.

/* called from newproc() since newproc() doesn't know about fpstates */
void
procfpinit(Proc *p)
{
	p->fpstate = FPinit;
	p->fpusave = (FPsave*)((uintptr)p->fxsave + 15 & ~15);
}

/*
 *  set up floating point unit before running new process; that is
 *  turn floating point off and allow the coprocessor not avail.
 *  trap to initialize the x87/sse on an as-needed basis.
 */
void
procsetup(Proc *p)
{
	fp->off();
}

/*
 * "clone" the fpu.  assume called from rfork() [sic], assume c api (regs dead
 * on function call return) [sic, maybe?] so we can get away with discarding the old
 * fp state by setting the fpstate to FPinit.
 */
void
clonefpu(PFPU *t, PFPU *s)
{
	/* child doesn't inherit fcr, etc.?  man page not conclusive */
	t->fpstate = FPinit;
	USED(s);
}

- erik