Date: Sat, 30 Dec 1995 12:52:49 +0000 From: Colman Reilly <creilly@maths.tcd.ie> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-hackers@freebsd.org Subject: Re: Linux emulator and Mathematica (Success!). Message-ID: <9512301252.aa12175@salmon.maths.tcd.ie> In-Reply-To: Message from Bruce Evans dated Saturday at 12:58.
next in thread | raw e-mail | index | archive | help
Content-Description: text
>The problem now is that mathclient crashes. Looking at the syslog output
>and the system calls, it would appearing to be crashing on a sigreturn:
> 791 mathclient CALL sigreturn(0xefbfc0e0,0xe,0)
> 791 mathclient RET sigreturn -1 errno 1 Operation not permitted
> 791 mathclient PSIG SIGBUS SIG_DFL
> 791 mathclient NAMI "mathclient.core"
>The signal it is responding to is a sigalarm.
>Now, from my reading of the sigreturn stuff and the Design and Implementa
tion of
>4.3BSD, it would seem that what is happening is that the sigreturn is try
ing
The Linux sigreturn() isn't fully implemented in the Linux emulator. It
returns ENOSYS.
Yeah, I saw that.
The problem here is probably quite different. Few applications call
sigreturn() directly. It is normally called as part of returning from
a signal handler. The kernel builds a signal trampoline with a
sigreturn() syscall at the end of it. The Linux emulator should
replace the code that builds the trampoline so that the syscall is
the Linux sigreturn() and not the BSD sigreturn(). It should also
convert the BSD sigcontext struct to the Linux sigcontext sigcontext
struct. It doesn't do this, so the Linux syscall that happens to
have the same number as the BSD sigreturn (#103 = Linux syslog())
is called instead. This is fudged to work by breaking the Linux
syslog() by pretending that it is the Linux sysreturn().
Oh. I thought that the system would have called the BSD sigreturn, since it had
been set-up by the BSD trampoline code, but now that I actually think about it
properly, the trap is just going to look-up the table associated with the
process.
>to restore some part of the state that it is not permitted to manipulate.
Would
>this seem reasonable to the kernel experts out there? One problem with th
is
Yes, it's quite likely that Mathematica is sophisticated enough to
manipulate the signal context. Since the sigcontext struct is
incompatible, this is unlikely to work, and could easily attempt
to change a protected register. However, this should result in
errno EINVAL, not EPERM.
That was confusing me. This all makes sense now. Thanks.
And what do you know? Adding the sigreturn call from -current into the 2.1R
version of the emulator makes Mathematica run! Now let's see whether
or not it works properly.
Thanks very much.
Colman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <9512301252.aa12175>