Help-Bus Errors

[Steve Dyer]

In article <MEISSNER.90Feb12175641 at curley.osf.org> meissner at osf.org (Michael Meissner) writes:
>When I was at Data General, we once grep'ed the current version of
>System V that we had at the time (probably V.1), and the only place
>that ever generated SIGSYS was if you passed something other than 0,
>1, or 2 as the whence argument to lseek.  Given that the Version 6
>PDP-11 UNIX only had a 'seek' call which took 3, 4, or 5 in addition
>to lseek's value, to multiply the offset by 512, it may be SIGSYS was
>a portibility guide that long since has unneeded.

Another instance in which SIGSYS was returned was in the INDIR system call
in PDP-11s.  The read and write system calls had an inline calling sequence
like this:

mov	fd, r0	/ fildes in R0
sys	READ	/ sys is the PDP-11 trap instruction, READ the syscall index 
.word	bufaddr
.word	count
/next instruction...

similarly for write.

You can see that this doesn't lend itself easily to C language calls
like read(fd, bufaddr, count), especially for pure text programs.
INDIR was used to implement the system call libraries, accomodating
"pure text" programs which could not modify inline system call arguments.

.text
read:	...
/ get fd from stack, place in R0
/ move bufaddr and count to dataarea[1] and dataarea[2]
sys	INDIR	/ INDIR == 0
.word	dataarea
/next instruction

.data
dataarea:	sys	READ
	.word 0
	.word 0

If dataarea[0] wasn't a trap instruction, you'd get a SIGSYS.


-- 
Steve Dyer
dyer at ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer at arktouros.mit.edu, dyer at hstbme.mit.edu