Messing with 0 ptr on m68020 & sys V / 68

[Dale Farnsworth]

Riku Kalinen (riku at clinet.fi) writes:
> Hardware: Motorola 8400 business - unix box with m68020
> Software: System V / 68 ver. 5.3.1 (?) [ Sys V rel 3 ]
> 
> Seems that my process's address space contains 1 k read-only nulls in
> very beginnig.
> 
> Questions:
>   1) Why? This causes reference thru 0 ptr to return 0 instead of core dump.

Yes, that's all it was intended to do.

>   2) Who sets up process's memory when it is started? Kernel?

Yes.  Actually, the null page doesn't get allocated at the start; it only
gets allocated (by the kernel) when it's first read.

>   3) Is there any good reasons to do this.

This is debatable.

The reasons are historical.  Once upon a time, the standard UNIX distribution
from AT&T ran on the PDP-11 family.  The instruction which began each program
(from crt0.o) just "happened" to have a zero-valued first byte.  Unfortunately,
a number of programs in the distribution relied on this "feature".  (They
contained constructs like this: { char *s; if (*s) x(); } rather than
{ char *s; if (s && *s) x(); } .)  When we did our first port to the 68000,
the instruction at location happened to *not* have a zero at location zero.
These programs failed to operate on the 68000 port as they did on the PDP-11.

Arguably, the correct thing to do was to track down all such programs and
fix them.  This would have been time consuming and it would have been
difficult to know when the task was completed, since many of the programs
failed in subtle ways or in paths that were rarely executed.

We did an easy fix which provided the same behavior on the 68000 port as on
the PDP-11.  We added an innocuous instruction to the beginning of crt0.o
which provided a zero at location 0.  (This also had the side effect of
making it as difficult to debug null pointer dereferencing problems on the
68000 port as on the PDP-11.)

Later, when we did the port of SVR3 to the 68020, the first word of crt0.o
was no longer mapped to location 0.  We again had to make the decision.
What was the correct behavior of the system when a program referenced
location 0? Of course the technically correct thing to do was to signal
an exception.  This would still require that the incorrect programs
described above be repaired.  (In fact, we have since fixed these programs,
but it is difficult to be sure that we have found them all.)  Complicating
the issue was the fact that VARs and end-users had written programs which
made use of the "zero at location zero" behavior and compatibility with
past releases was (and remains) important.

We opted to map a "zero on demand" page to page zero.  This provides the
"zero at location zero" behavior with no overhead to a process which does
use the behavior.  Unfortunately, it remains more difficult to debug null
pointer dereferencing problems than if an exception were signaled.

I must emphasize that programs should *not* rely on this behavior.  It
may not be maintained in future ports.  In fact, some existing Motorola
UNIX ports already signal an exception on a read of location zero.

These are my personal recollections and do not represent Motorola policy.

-Dale

-- 
Dale Farnsworth		602-438-3092	noao!asuvax!nud!df