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