Apparently, On Tue, Oct 01, 2002 at 11:12:02AM -0400,
Daniel Eischen said words to the effect of;
> 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...
The point is that the signal trampoline automatically uses the new or
old system calls because its linked with libc. Otherwise you need
a different signal trampoline in the kernel for each version of sigreturn,
and some way to determine the right one. The 0x01ds16 hack only works
for so long.
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message