Implementing NULL trapping (was: What machines core dump on deref of NULL?)

[Chris Lewis]

As faulting on NULL dereference is often an explicit decision on the
part of the O/S's memory management/loader definition people, I was
wondering if anyone knew how to modify COFF to implement NULL trapping
on COFF systems...

Background: I distribute psroff and some of the code has been caught
with different compilers on other systems with the infamous null
dereference (ala *p = NULL; i = *p;, or worse, *p = NULL; i = p->something).
I've managed to find and swat most of these, but it would be nice if
I could fix my compiler/loader/OS to trap them *here*.

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"),
which lays out where .text/.data/.bss will be relocated and arranged
in the memory image.  Some system implementations of COFF have
various ifiles that describe how the images are to be built for
various memory models (eg: COFF implementations on 286 or shared vs.
non-shared on other systems - corresponding to the magic numbers).  The
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).  What's really interesting is that
using the implicit "ld" layout causes at least *some* of the
COFF headers to precede the run-time startoff at virtual 0 -
in fact, the load module's magic number is at 0 in the executing
image!  (so pointer chasing can get rather nasty and "printf("%s", 0)"
prints a string of garbage)

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 attacked this from another approach, by putting a filter
in front of the assembler that inserts checking code immediately
prior to all register dereferences.  But, it (at least in my
few minutes of hacking) misses some dereferences, and explodes
the binary size by something near a factor of 2 - I'd rather
it didn't effect the program except for relocation factors.

[No, I'm too ashamed to post it...]

To reiterate a remark I made before:

    All programmers should be forced to develop their UNIX software
    on systems that have a thermonuclear device triggered by the
    access bits on page 0....

I'm just trying to get there myself ;-)

[Yes, I know that NULL isn't necessarily 0 from a C language theoretical
point - I'm just trying to implement a testing mechanism for my specific
implementation...]
-- 
Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis
Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list