From:	CSBVAX::MRGATE!@KL.SRI.Com:info-vax-request@kl.sri.com@SMTP 15-JUL-1987 00:58
To:	EVERHART
Subj:	Re: Help with a Kernal mode macro program

Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Sat 11 Jul 87 13:56:44-PDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
	id AA11219; Sat, 11 Jul 87 13:36:33 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for info-vax@kl.sri.com (info-vax@kl.sri.com)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 11 Jul 87 13:36:33 GMT
From: ece-csc!ncrcae!ncr-sd!hp-sdd!ucsdhub!jack!man!crash!jeh@mcnc.org  (Jamie Hanrahan)
Organization: Crash TS, El Cajon, CA
Subject: Re: Help with a Kernal mode macro program
Message-Id: <1369@crash.CTS.COM>
References: <870708122836.001@sitvxb>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com

In article <870708122836.001@sitvxb> dstevens@sitvxb (David L Stevens) writes:
>
> ...the MOVC3
> statement in the Kernal Mode code, crashes the system every time I run it.

I replied to this via mail, but since then several not-quite-correct
responses have been posted as news, so here goes...

The folks who point out that MOVC3 clobbers R0-R5 are correct.  (And,
by the bye, LOC3 hits R0-R3.)  BUT, simply mentioning R2 through R5
in the kernel (not "kernal", please!) mode routine's entry point mask
is not sufficient to avoid the crashes.  

The code shown is calling the VMS system routines EXE$IOLOCKR (lock
I/O data base via mutex for read) and EXE$IOUNLOCK (unlock I/O data
base mutex).  These routines require R4 to point to the current 
process's PCB.  The call to IOLOCKR works because the $CMKRNL service
calls the target routine with R4 pointing to the PCB, but after the 
MOVC3, R4 contains 0.  The mutex-handling routines check to ensure
that R4 is pointing to a valid PCB and bugcheck if it doesn't; hence
the crash.  

R4 can be pushed at the beginning of the routine and popped just
before the call to UNLOCK, or pushed and popped around the MOVC3s. 
Personally, I would put the following statement just before the calls
to both EXE$IOUNLOCK and EXE$IOLOCKR:

	MOVL    G^SCH$GL_CURPCB, R4     ; get addr of cur proc PCB

Sure, it's not necessary for IOLOCKR because of the context that 
this code happens to run in... but that might change someday.  
The MOVL makes the code less context-dependent, and also more
understandable.  

One other thing:  All references to system-space labels 
(EXE$IOLOCKR, EXE$UNLOCK) should be preceded with the G^ prefix
to ensure that they're position independent.  

DISCLAIMER:  Names of system-space labels in the above were typed
from memory.  The suffixes are correct but the prefixes (EXE$, 
SCH$, etc.) may be mixed up... it's late/early/not good.