cox (05/31/82)
Has someone out there investigated the possibility of dynamically linked subroutines? If so, please reply with a mail address so we can discuss this further, else your reasons for why it's foolish to even try. The wish is simple: to pre-build C subroutines (in a manner to be determined here) into files which can be read(2) into arbitrary core locations by a substrate program and executed as location-independent code, presumably executed via a pointer to function. A portable solution would be nice...but for now I'd settle for a recipe for making this work on the VAX under 4.1bsd. My working assumption is that a subset of C can be used such that position-independent code gets generated (I've not yet verified this). Then the substrate program is linked with "ld -r", producing a file which is used to resolve any external symbols (C runtime library, etc) for each subsequent module to be dynamically linked via "ld -A". I'm having two problems: (1) "ld -A" complains "multiple definition" for every symbol it's asked to define (perhaps a bug in ld?), and (2) the ld documentation specifically states that a specific load address is being used for the linking (_end of substrate). But is any real USE being made of this assumption in the output file? In other words, I'd intend to read such files into arbitrary addresses...I can't assume _end is free. This problem arises in the context of an implementation of Smalltalk 80 I'm building that currently uses the C compiler for code generation. I'm trying to determine if this code generation technique can survive into the next bootstrap cycle when objects are held in disk files instead of core and paged in automatically when referenced. The smalltalk methods are managed as C subroutines currently, and so I need a way to dynamically page them in also. Note that addresses of code read is managed manually...there's no need to scan the world looking for arbitrary externs to non-resident code. The only alternatives I see if this approach fails is writing my own code generator or moving to an interpreter...I'd much rather live with the C compiler if it can be made to work. Dr. Brad J. Cox ITT Programming Technology Center Advanced Technology Department 1000 Oranoque Lane Stratford, Ct 06497 (203) 375-0200 decvax!ittvax!cox