Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!cernvax!chx400!chx400!bernina!neptune!inf.ethz.ch!brandis
From: brandis@inf.ethz.ch (Marc Brandis)
Newsgroups: comp.unix.aix
Subject: Re: Invalid pointer traps (S/6000)
Keywords: Traps, NIL, NULL, invalid pointers
Message-ID: <25527@neptune.inf.ethz.ch>
Date: 18 Feb 91 09:16:20 GMT
References: <24518@neptune.inf.ethz.ch> <1991Feb12.033513.27494@athena.mit.edu> <1991Feb13.012239.24125@arnor.uucp>
Sender: news@neptune.inf.ethz.ch
Reply-To: brandis@inf.ethz.ch (Marc Brandis)
Organization: Departement Informatik, ETH, Zurich
Lines: 60

The replies I got so far about NULL pointer accesses seem to indicate the
following two things.

	1) The instruction scheduler may decide to execute a load speculatively
	   before it has checked the pointer.

	2) A lot of code would break if *(NULL) != 0.

Before I comment on these issues, let me briefly explain what I found on the
machine. The whole address range from 0x0 to the end of the data segment is
readable, with some areas also writable. There is an additional area for the
stack which is both readable and writable. Since the data segment is usually
allocated at address 0x20000000, this results in a space of about 600 megabytes
which is readable. Due to the inverted page tables in the S/6000, these are
not just shared page table entries pointing to a single page but in fact are 
allocated in memory the first time they are accessed. A program that I wrote
to scan this area caused a lot of paging traffic.

So, this whole stuff has been implemented somewhere in the page fault handler
of AIX.

Let me now comment on the above two points. I do not think that there are very
many cases in which the speculative execution would be of any help, as the
S/6000 does speculative execution in hardware. You can safely place the branch
in front of the load and the machine will speculatively execute the load until
the it is sure whether the result is needed or not. Note that this is 
advantegeous to using a load that has been moved in front of the branch, as
all kind of exceptions or cache misses have to be handled. 

In fact, I looked at the code generated by the XLC compiler with all 
optimizations turned on for several pieces of code that traverse data 
structures including NULL pointers, and I did not find a single example where
the compiler inserted such a speculatively executed load.

I tend to believe more in the second issue that has been raised, that a lot of
code would break. However, I checked several UNIX systems and I found that this
does not seem to be the case for all systems. The test is whether the machines
trap on a read from address 0, sending an segmentation violation signal to the
application.

	Sun-3, SunOS 4.0.3			traps
	SparcStation, SunOS 4.0.3		traps
	DECstation 5000, Ultrix V4.1 (Rev. 52)	traps
	IBM RS/6000 530, AIX 3			no trap
	Sequent Symetry S81, Dynix V3.0.17.9	no trap

So, it must be possible to make common UNIX programs run without having reads
from 0 returning 0. I have to say that I feel a little bit unsecure using 
these systems, as programs that need to access stuff that they do not have
allocated contain bugs for sure. 

But still, it would be great if there were a way to turn this off. In the long
run I hope IBM is able to write their code so that they would not require
reading through a NULL pointer.


Marc-Michael Brandis
Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology)
CH-8092 Zurich, Switzerland
email: brandis@inf.ethz.ch