Xref: utzoo comp.unix.wizards:22780 comp.unix.i386:6565
Path: utzoo!utgpu!watserv1!watmath!att!cbnews!junk1
From: junk1@cbnews.att.com (eric.a.olson)
Newsgroups: comp.unix.wizards,comp.unix.i386
Subject: Re: Implementing NULL trapping on AT&T SVR3.2(.2)
Message-ID: <1990Jul6.115941.11096@cbnews.att.com>
Date: 6 Jul 90 11:59:41 GMT
References: <412@minya.UUCP> <13291@smoke.BRL.MIL> <1990Jul5.174608.17336@eci386.uucp>
Sender: Eric A. Olson
Organization: AT&T Bell Laboratories
Lines: 28

In article <1990Jul5.174608.17336@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes:
>
>On System V (I'm 386/ix 1.0.6), the memory layout of an executable
>program is controlled by a default loader control file ("ifile"),
...
>386 one uses the "defaults" built into "ld"'s binary, which I can't
>seem to be able to reconstruct from the 386/ix Guide entries for
>the loader.  Eg: by manually creating an ifile, I can't seem to be
>able to build a binary that runs (and many variants won't even link - the
>examples seem defective).  
...
>
>Anyways, two questions:
>	1) Has anybody got a working ifile for a 386 UNIX system
>	   that I could try playing with?
>	2) Has anybody got a working ifile for 386 UNIX systems
>	   that explicitly maps *out* at least the first couple
>	   of pages at virtual 0 so that null dereferences fault?
>	   Is this possible?  (does the 386/ix execution model
>	   memory requirements forbid this?)
	
	I'd  like to do this too, but I've been seeing the same
	results you mention... The '-z' flag causes the loader
	to issue a complaint that the default bond address is
	not within allocated memory, and no ifile that I can 
	construct seems to produce a runnable program.

	Has anybody (Conor?) been able to do this?