Implementing NULL trapping on AT&T SVR3.2(.2)

eric.a.olson junk1 at cbnews.att.com
Fri Jul 6 21:59:41 AEST 1990


In article <1990Jul5.174608.17336 at eci386.uucp> clewis at 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?



More information about the Comp.unix.i386 mailing list