Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!plx!dlb!megatest!djones
From: djones@megatest.UUCP (Dave Jones)
Newsgroups: comp.unix.wizards
Subject: runtime linking (was: Aliasing text and data segments of a process)
Message-ID: <245@goofy.megatest.UUCP>
Date: 3 Feb 88 22:17:03 GMT
References: <208@sdti.UUCP>
Organization: Megatest Corporation, San Jose, Ca
Lines: 27

in article <208@sdti.UUCP>, mjy@sdti.UUCP (Michael J. Young) says:
> 
> In article <246@vcvax1.UUCP> naren@vcvax1.UUCP (naren) writes:
>>	Doug Gwyn is right about architectures that enforce distinctions 
>>between code and data spaces (ex: 80386). On UNIX/386, an sbrk() allocates 
>>space in the Data Segment of the process. Type casting this pointer and 
>>issuing a 'call' to this address will result in a protection exception. 
> 
> This happens on many other 80x86 ports as well.  Microport (the only 286
> port I'm familiar with) enforces separation between text and data regions
> as well.  Unfortunately, they don't seem to provide ld(1) options to
> override the protection. 

Well, don't BUY those operating systems! (Too late?)

On a related note:  I have some applications for which the runtime
load trick is just perfect. The SunOS-3 linker, ld(1), supports the concept.
(-A flag.)

But if you do the link-edit part, ld -A, before load time, the incremental 
load-file is dependant on the symbol resolution of the main program remaining
unchanged.  So, one wants to do the incremental link-edit at runtime.  

But ld(1) is too SLOWWWWW.  I wrote a replacement, "dynald", to do the 
incremental link, and it does a small file in from 6 to 50 milliseconds.
The SunOS ld(1) takes six seconds!  It makes the assembler, as(1), look almost
speedy by comparison.