Xref: utzoo comp.emacs:4637 gnu.emacs:161
Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!triceratops.cis.ohio-state.edu!karl
From: karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
Newsgroups: comp.emacs,gnu.emacs
Subject: Re: Possible to do #undef NO_REMAP for V/386?
Message-ID: <27435@tut.cis.ohio-state.edu>
Date: 14 Nov 88 17:00:19 GMT
References: <442@arisia.Xerox.COM>
Sender: news@tut.cis.ohio-state.edu
Lines: 48
In-reply-to: weikart@arisia.Xerox.COM's message of 13 Nov 88 03:19:05 GMT

weikart@arisia.Xerox.COM (Scott Weikart) writes:
   > I do not know the answer.  The problem is that the data space starts
   > well away from the text space.  Supposedly ld -N can move them closer,
   > but that appears to be broken: it doesn't work for any program I've
   > tried, much less GNU emacs.  I suggest posting to gnu.emacs and seeing
   > if anyone has found a way.  Let me know if you find one.  Good Luck!

   Does anyone know if ld -N works in Release 3.1 or 3.2 of V/386?

   Also, it has been suggested that #undef NO_REMAP isn't as important with
   System V release 3, because under Vr3 a new exec shares an existing data
   region, and uses copy on write to replace the data region pages that get
   changed, so that in general there is only one copy of the Emacs libraries in
   memory even if there are multiple Emacses running.  Is this correct?

Writing as the person who did the first port to real, original, AT&T
VAX-11/780 SysVRel5.0 (borrowing heavily from the work of others who
ported it to semi-SysV things like Duals and Strides) under GNU Emacs
16.54 about 3 years ago...

You do ***NOT*** want to use ld -N.  The `feature' which -N provides
for you is to make the text and data segments of the resulting binary
into ONE SEGMENT, which is to say, it is not write-locked and shared
among the N possible incarnations of the binary.  This means Bad
Things for how hard your system will swap when the 2nd incarnation of
it starts up.  Just because you might be on a little PC-sized 386
thing isn't sufficient justification - sometime you'll have a window
with one sitting there while kicking off an editor in another under
your mailer, and then your system will start to choke and die.  I was
using a 4Mb 780 which choked quite badly enough; I'd hate to think
what your disc seek time will do to you.

So, yes, ld -N puts text & data closer together...by making them the
same thing, and the one just runs straight into the other.  Do you
really want to chase down a bad-pointer bug, when you have scribbled
over code with that bad pointer, and so now mysteriously fails at
random times?  SysVRel2 & higher want to separate text & data by
fairly large amounts of empty address space; it is in your best
interest to leave them separated and put up with the fixed lisp code
being in data space.

This is to say that your comment at the end about the sharing of
spaces is correct anyway; that VM, when done properly, doesn't mess
with copying things, even in writable data space, until someone
actually performs a write to make their data space different from
yours.

--Karl