Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!ucsd!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: dumping core on *(NULL) is not a function of your processor
Message-ID: <62735@sun.uucp>
Date: 4 Aug 88 03:07:47 GMT
References: <253@iconsys.UUCP> <495@cvaxa.sussex.ac.uk> <11955@ncoast.UUCP> <2835@ttrdc.UUCP>
Sender: news@sun.uucp
Lines: 22

> A new magic number is nice 'cause then you could simply convert your existing
> executables.  This would save having to recompile stuff, and would let you
> check the products of vendors who only provide binary distributions.

No, you can't.  The problem is not that implementations of UNIX (or other OSes,
for that matter) on some machines construct an address space with a page full
of uninteresting stuff starting at location 0; the problem is that they put the
first instruction to be executed when running an image at location 0, and put
other objects (code or data) into that page.  If you just patch the magic
number, the program will still start at location 0; however, since there
wouldn't be a location 0, it would bomb out.

Since executables tend to lack relocation bits, you can't just shuffle the
address space of the program up by one page, either; absolute references to
objects in the first page will bomb out.

> Could a system call be added (horrors!) or an existing call modified to
> map out page 0 (or for that matter, any arbitrary page you chose)?

Either of those could be done, but they have the same problem; if the program
wasn't built to run in an address space lacking the first page, it'll die
whenever it references something that legitimately exists within that page.