Path: utzoo!attcan!lsuc!eci386!clewis From: clewis@eci386.uucp (Chris Lewis) Newsgroups: comp.unix.wizards Subject: Implementing NULL trapping (was: What machines core dump on deref of NULL?) Message-ID: <1990Jul5.174608.17336@eci386.uucp> Date: 5 Jul 90 17:46:08 GMT References: <31079@cup.portal.com> <13226@smoke.BRL.MIL> <412@minya.UUCP> <13291@smoke.BRL.MIL> Reply-To: clewis@eci386.UUCP (Chris Lewis) Organization: Elegant Communications Inc. Lines: 61 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