Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ncar!gatech!udel!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu!<UNAUTHENTICATED>+
From: Richard.Draves@CS.CMU.EDU
Newsgroups: comp.os.mach
Subject: Re: using Mach exceptions and Unix signals in the same task
Message-ID: <0bdtaqe00hsQJ3kFJ4@cs.cmu.edu>
Date: 31 Jan 91 04:14:46 GMT
References: <1991Jan30.150711.8040@mintaka.lcs.mit.edu>
Organization: Carnegie Mellon, Pittsburgh, PA
Lines: 52
In-Reply-To: <1991Jan30.150711.8040@mintaka.lcs.mit.edu>

> Excerpts from netnews.comp.os.mach: 30-Jan-91 using Mach exceptions and
> U.. Elliot Kolodner@lcs.mit. (616)

> I have ported a program that makes extensive use of the Unix signal
> facility
> to Mach.   Now I need to modify the program.  The modification requires
> the
> use of Mach exceptions.  However, I'd like to change the program itself
> as
> little as possible.  In particular, I prefer not to modify the signal
> handlers.  Is there a way to catch the Mach exceptions that I require in
> an
> exception handler, and pass the rest back to system to be redelivered to
> the
> program as Unix signals, i.e. is there a way for some exceptional
> conditions
> to be processed as Mach exceptions and others to be processed as Unix
> signals.

Let me first review how Mach handles exceptions.  Threads and tasks can
have exception ports.  New tasks inherit their exception port from their
parent.  New threads have a null exception port.  The kernel makes
exception_raise upcalls to exception ports.  When a thread takes an
exception (illegal instruction, touches bad memory, breakpoint, etc.)
the kernel first tries the thread's exception port, if present, and if
that fails then the thread's task's exception port, if present.  An
exception_raise upcall fails if the exception server returns a value
other than KERN_SUCCESS.  If no exception server takes responsibility
for an exception (no exception ports, or the servers returned
non-KERN_SUCCESS), then the kernel terminates the thread's task.

All exceptions go through this mechanism.  However, the default
exception server is a task inside the kernel that converts the
exceptions into Unix signals.  Normally threads have a null exception
port, and tasks have an exception port for this default service.  (In
Mach 3.0, the default exception service is the responsibility of the
Unix emulation and isn't in the kernel.)

There are several things you can do.  First, if you want some threads to
get signals and others to contact your exception service, you can
install your exception port in selected threads.  Second, you can
install your exception port in all threads, and have your exception
server examine the arguments to the exception_raise upcall and return
non-KERN_SUCCESS for those exceptions that should get turned into
signals.  The kernel will retry with the task's exception port, for the
default exception service.  Third, your exception server can forward the
exceptions it doesn't want to handle to the default exception service in
the kernel.  Your task would retrieve its original exception port, for
forwarding, and install its own exception port.  And of course there are
various combinations of these strategies.

Rich