home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.unix.sysv386:16311 comp.unix.sys5.r4:459
- Path: sparky!uunet!auspex-gw!guy
- From: guy@Auspex.COM (Guy Harris)
- Newsgroups: comp.unix.sysv386,comp.unix.sys5.r4
- Subject: Re: mmap and segv, a better way. Was: Re: av386mon source posted to alt.sources
- Message-ID: <15387@auspex-gw.auspex.com>
- Date: 7 Nov 92 09:52:18 GMT
- References: <1992Oct2.184624.4441@omega.ssw.de> <1992Nov6.181051.8438@cichlid.com>
- Sender: news@auspex-gw.auspex.com
- Followup-To: comp.unix.sysv386
- Organization: Auspex Systems, Santa Clara
- Lines: 23
- Nntp-Posting-Host: auspex-gw.auspex.com
- Nntp-Posting-Host: bootme.auspex.com
- Originator: news@auspex-gw.Auspex.COM
-
- >An even cleaner way works on SunOS. You may want to check if sysvr4
- >supports this. In the signal handler if you simply return the
- >OS retrys the faulting instruction.
-
- Err, in *some* SunOS releases on *some* processors, it does so.
-
- It didn't do so on the 68K Suns until 4.1 or 4.1.1 or so; the problem is
- that there's some amount of context information required to continue the
- faulting instruction, and that information wasn't saved until the
- release in question.
-
- It should work OK on SPARC and 386-based Suns.
-
- I.e., it's not a question of whether SVR4 supports it, it's a question
- of whether SVR4 *on the platform in question* supports it (although it
- probably does, in order to make the Bourne shell work, unless they back
- the SIGSEGV hack out in SVR4, as we had to do at one point in SunOS).
-
- >Oh yes, the exact details of what address was accessed, program counter, etc
- >is supplied to the signal handler (3rd argument is pointer to a struct that
- >contains this info, as I recall).
-
- In SVR4, that's done as well, although in a different form.
-