Subject: Re: 4K vs. 8K pages in GAS
To: Curt Sampson <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 09/17/1996 00:12:30
On Mon, 16 Sep 1996 23:34:09 -0700 (PDT)
Curt Sampson <email@example.com> 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 ld.so 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 - http://www.bayarea.net/~thorpej/forest/ --
Jason R. Thorpe firstname.lastname@example.org
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