Xref: utzoo comp.unix.questions:19852 comp.unix.wizards:20574 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!spdcc!dyer From: dyer@spdcc.COM (Steve Dyer) Newsgroups: comp.unix.questions,comp.unix.wizards Subject: Re: Help-Bus Errors Message-ID: <1655@ursa-major.SPDCC.COM> Date: 13 Feb 90 04:50:50 GMT References: <1810@lzga.ATT.COM> <1990Feb10.192028.16025@eddie.mit.edu> Reply-To: dyer@ursa-major.spdcc.COM (Steve Dyer) Organization: S.P. Dyer Computer Consulting, Cambridge MA Lines: 46 In article meissner@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@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu