Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!arisia!sgi!shinobu!odin!maddog!pkr
From: pkr@maddog.sgi.com (Phil Ronzone)
Newsgroups: comp.arch
Subject: Re: 68000 prehistory, was IBM PC prehistory
Message-ID: <2926@odin.SGI.COM>
Date: 18 Jan 90 05:46:32 GMT
References: <1990Jan12.042336.6123@esegue.segue.boston.ma.us> <9324@cbmvax.commodore.com> <2825@odin.SGI.COM> <7S31O_3xds13@ficc.uu.net>
Sender: news@odin.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 23

In article <7S31O_3xds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>> loader has been told that the distance (roundup) from data to bss is
>> 64K, and you've been marked shared text, and you'd like to load
>> on a machine with a 128K segment boundary, all the relocation in the
>> world is not going to help you.
>
>Sure it is. Nobody says that the different segments of the program have
>to be relocated at a fixed distance. You can have as many chunks of code
>in the load module as you can stand, and load them anywhere, once you have
>relocation working.

You deleted the first line which said this was a cased of a shared text
module. In a shared text module, the loader/linker MUST know the segment
round-up size, because after the exec() the text seg is going to be read
only.

If your data is in there, it's going to be hard to write it ...


------Me and my dyslexic keyboard----------------------------------------------
Phil Ronzone   Manager Secure UNIX           pkr@sgi.COM   {decwrl,sun}!sgi!pkr
Silicon Graphics, Inc.               "I never vote, it only encourages 'em ..."
-----In honor of Minas, no spell checker was run on this posting---------------