runtime linking (was: Aliasing text and data segments of a process)

[Dave Jones]

in article <208 at sdti.UUCP>, mjy at sdti.UUCP (Michael J. Young) says:
> 
> In article <246 at vcvax1.UUCP> naren at 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.