Subject: Re: 4K vs. 8K pages in GAS
To: Curt Sampson <>
From: Jason Thorpe <>
List: m68k
Date: 09/17/1996 00:12:30
On Mon, 16 Sep 1996 23:34:09 -0700 (PDT) 
 Curt Sampson <> wrote:

 > So my first question here is, how different are m68k machines with
 > 4K and 8K page sizes? Are they really not binary compatable? Why
 > not? Or, if they are, why do we have separate magic numbers?

The only port that uses the 4k LDPGSZ is the hp300 ... this is historical 
cruft that I plan on fixing RSN... I recently committed compat_m68k4k to 
the post-1.2 sources which will allow current hp300 installations to use 
legacy binaries and shared libs.  I have a strange kernel bug to chase 
down, and the linker to frob with (so that the old static libs will work, 
too), and then the hp300 will get switched.

The history is this: the hp300 port, long before it was part of NetBSD, 
used a 4k "linker page size", to match the 4k hardware page size.  The 
hp300 is locked into this size, because some models have an HP MMU 
(which, as far as I can tell, can't be reprogrammed to use a page size 
other than 4k).  Later comes NetBSD/sun3.  The sun3 is locked into an 8k 
hardware page size, because of the Sun MMU.  Since the VM system can 
transparently handle the case of using an 8k "linker page size" on 4k 
hardware page size systems, and the 8k systems can't safely use the 4k 
format (it would require lots of gunk in the run-time loader, exec 
code, and would require page 0 to be mapped) the 8k format was chosen.  
Unfortunately, the hp300 port was never changed (hey, don't blame me... :-)

Well, it's about time the hp300 port catches up in this regard...

 > If they aren't, perhaps we need to make real separate architectures
 > for these two types of machines, rather than lumping them all under
 > `m68k'. Or can someone think of a better way around this problem?

Quite literally, the only differences are:

	- The magic number in the a.out header, and

	- Text starts at 4096 on 4k executables, and 8192 on 8k executables.

	- Sections are rouned to 4k boundaries on 4k executables,
	  and 8k boundaries on 8k executables.

The linker can be taught to make 4k .o files into 8k executables (text 
addr is chosen at link time, and the rest is just section rounding; the 
linker will fixup the symbols and the Right Thing should happen).  I've 
already committed a `slight hack' to to allow it to load 8k shared 
libs with 4k executables (on 4k hardware page size systems only; start of 
text on 4k executables prevents compat_m68k4k from working on 8k hardware 
page size systems... static executables could be kludged into working, 
but dynamic ones are much harder, and really, what's the point? :-)

The real solution to the problem is to fix the hp300 (working on it :-).

 -- save the ancient forests - -- 
Jason R. Thorpe                             
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939