On Mon, 30 Sep 2002, Peter Wemm wrote:

> Daniel Eischen wrote:
> > At the end is a potentially longer term fix for the ABI
> > breakage that was introduced when the i386 mcontext_t
> > was changed/enlarged.
> 
> > -           ret = set_fpcontext(td, &ucp->uc_mcontext);
> > -           if (ret != 0)
> > -                   return (ret);
> > +           /*
> > +            * Intentionally ignore the error to keep binary
> > +            * compatibility with applications that fiddle with
> > +            * the FPU save area in the context.  The kernel
> > +            * now saves the FPU state in the context, but it
> > +            * gets corrupted by those applications that try
> > +            * to work around the kernel NOT saving it.
> > +            */
> > +           (void)set_fpcontext(td, &ucp->uc_mcontext);
> 
> Maybe we could have something like this instead?
> 
>       ret = set_fpcontext(td, &ucp->uc_mcontext);
> #if !defined(COMPAT_FREEBSD4) && !defined(COMPAT_43)
>       if (ret != 0)
>               return (ret);
> #endif
> 
> ie: ignore the error only if we have to be compatable.

Sure that's totally doable.  It might not be enough to just
call set_fpcontext() and ignore the error.  Thinking a bit
more about it, the mc_len, mc_fpformat, and mc_ownedfp fields
now occupy the first couple of slots where fpregs[] used to be.
The format of an fnsave() stores the control, status and tag
words in these slots.  There are 32-bits of storage allocated
for each of these, but the fnsave (according to what I
see in npx.h), only uses the lower 16 bits.  It might be
possible to save a control word or status word that turn
out to be valid for mc_fpformat or mc_ownedfp (0, 1, or 2).
In this case we'd think the FP context was valid, and try
to restore it (it would be trashed).

I think if we put some magic in the upper 16 bits of
mc_ownedfp, mc_fpformat, then we could prevent this.

> Longer term, I was thining that we could/should do what sparc64 does, ie:
> libc provides the trampoline and it can then call the correct sigreturn
> syscall.  That means we add a new sigreturn syscall each time we
> significantly break the sigreturn ABI (as in this case) and applications
> will be able to use the correct one.  Paired with a new sigaction syscall
> which would specify the "new" context format we can then be future proof.

Sounds good.  If we added a new sigaction and sigreturn now, we can
still do the same thing, without having the trampoline in libc.
I thought the point of having the trampoline in libc would prevent
having to create new syscalls...

-- 
Dan Eischen


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to