tam@endor.harvard.edu (Va-On Tam) (11/30/88)
Earlier I asked how to restart a program at a different location
from the faulting instruction at a virtual memory page fault in
Sun3/60 hardware.
I got the following replies. Thanks for the responses.
----------------------------------------------------------
From pardo@june.cs.washington.edu Mon Nov 21 20:09:24 1988
Received: by june.cs.washington.edu (5.59/6.13+)
id AA13966; Mon, 21 Nov 88 17:06:31 PST
Date: Mon, 21 Nov 88 17:06:31 PST
From: pardo@june.cs.washington.edu (David Keppel)
Return-Path: <pardo@june.cs.washington.edu>
Message-Id: <8811220106.AA13966@june.cs.washington.edu>
To: tam@endor
Subject: Re: Restarting after virtual memory page fault
Newsgroups: comp.arch
In-Reply-To: <630@husc6.harvard.edu>
Organization: U of Washington, Computer Science, Seattle
Cc:
Status: R
...
Sure. You can start it anywhere just by loading the appropriate PC
when you return from the fault, but that's probably hard (e.g., you
don't know where that 'somewhere' should be). Better might be to send
a signal. Define a new signal SIGPGFAULT, have your program register
a handler for that signal when the program starts, and everything else
happens in user code.
;-D on ( Of course the program still needs to know what it's doing ) Pardo
--
pardo@cs.washington.edu
{rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
-------------------------------------------------------------------
From @cs.utexas.edu:auspex!guy@uunet.UU.NET Tue Nov 22 14:12:29 1988
Received: by husc6.harvard.edu; Tue, 22 Nov 88 13:40:01 EST
Received: by harvard.harvard.edu; Tue, 22 Nov 88 12:39:51 EST
Posted-Date: Tue, 22 Nov 88 09:16:19 PST
Received: from uunet.UU.NET by cs.utexas.edu (5.59/1.22)
id AA12652; Tue, 22 Nov 88 11:30:51 CST
Received: from auspex.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA12503; Tue, 22 Nov 88 12:30:29 EST
Received: by com (4.0/SMI-4.0)
id AA01495; Tue, 22 Nov 88 09:16:19 PST
Date: Tue, 22 Nov 88 09:16:19 PST
From: @cs.utexas.edu:auspex!guy@uunet.UU.NET (Guy Harris)
Message-Id: <8811221716.AA01495@com>
To: @cs.utexas.edu:uunet!husc6!endor!tam@uunet.UU.NET
Subject: Re: Restarting after virtual memory page fault
Newsgroups: comp.arch
In-Reply-To: <630@husc6.harvard.edu>
Organization: Auspex Systems, Santa Clara
Status: R
>My question concerns specifically about Sun3/60 hardware:
Nope. The Sun-3/60 is just a 68020 with glue around it, and instruction
continuation is done by the 68020, not the glue. I suggest you check
out Motorola's 68020 book for a description of bus error handling (page
faults get reported as bus errors) and instruction continuation.
>Is there a way to restart a program at a *different* location
>than the faulting instruction at a virtual memory page fault?
>From user mode under SunOS? No. The OS doesn't keep the big bus error
stack frame (what Henry Spencer refers to as "stack puke") around, so
you cannot catch SIGSEGV, fiddle with the stack puke, and return from
the SIGSEGV handler expecting to continue the instruction. (You can't
even do it if you *don't* want to fiddle with the stack puke.)
>From kernel mode (assuming you can whack on the kernel code, or are
writing your own OS), or from user mode on your own OS? Check the
Motorola manual.
--------------------------------------------------------------------
From mnetor!geac!geaclib!daveb@uunet.UU.NET Wed Nov 23 01:11:24 1988
Received: from mnetor.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA22311; Wed, 23 Nov 88 01:08:52 EST
Received: by mnetor.UUCP (smail2.3)
id AA07793; 23 Nov 88 01:03:34 EST (Wed)
Received: by geac.UUCP (smail2.5)
id AA01534; 23 Nov 88 00:40:20 EST (Wed)
Date: Tue, 22 Nov 88 20:39:23 est
From: geaclib!daveb@uunet.UU.NET (David Collier-Brown)
Message-Id: <8811230139.AA11934@geaclib.uucp>
To: tam@endor
Subject: Re: Restarting after virtual memory page fault
Status: R
tam@endor.harvard.edu (Va-On Tam):
> My question concerns specifically about Sun3/60 hardware:
> Is there a way to restart a program at a *different* location
> than the faulting instruction at a virtual memory page fault?
Well, I can't comment on the Sun (although it seems almost
straightforward), but I do remember the ICL 29XX series happily
branching out of the fault handler to the programs' "Oh drat, a
fatal error hasoccurred" address. This is the same address we used
when we wanted to force a breakpoint on something that ran too
long: suspend the normal process and say "enter prog-name 100" and
watch it go down gracefully.
--dave (A former co-op student at ICL) c-b