dillon@CORY.BERKELEY.EDU.UUCP (06/06/87)
Here is a neat little tidbit which came out of an operating systems project I'm working on: Named library vectors, initialized on program startup. It would make a *GREAT* addition to 1.3 (can somebody give me Dale's email address?). It's really simple. The executable has a new hunk type which is basically a table of the names for all unresolved symbols the linker found when the program got linked. The loader would then fill in a vector table with the function vectors specified BY NAME in this hunk type. Thus, you no longer have static offsets, or even have to deal with specific libraries, and your programs become binary-portable to new versions of the OS without lifting a finger or even re-linking. As an added plus, the loader can complait and abort the load if any of the unresolved symbols is actually unresolved... doesn't exist in a library. The unresolved symbols would apply only to unresolved function calls. Of course, you would provide EXEC calls to add/delete functions to this new type of library where the vectors are named. * making stdio and other routines run-time libraries becomes trivial * executables are even SMALLER * You needn't link with large static libraries... or any at all. * programs are completely compatible between OS versions, especially if this new huck has an "OS version expected" field. * by providing an interface to the original library types via this new scheme, you would simply relink existing object with a link-time library which *doesn't* contain the library routines to make it work with the new libraries (assuming you have a new linker which supports the new hunk type). -Matt
hadeishi@husc4.HARVARD.EDU (mitsuharu hadeishi) (06/06/87)
In article <8706060558.AA04607@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > Here is a neat little tidbit which came out of an operating >systems project I'm working on: Named library vectors, initialized on >program startup. It would make a *GREAT* addition to 1.3 (can somebody >give me Dale's email address?). > > It's really simple. The executable has a new hunk type which is >basically a table of the names for all unresolved symbols the linker found >when the program got linked. The loader would then fill in a vector table >with the function vectors specified BY NAME in this hunk type. > . . . > > * making stdio and other routines run-time libraries becomes trivial What about load speed? AmigaDOS is already pretty slow at loading executables, and doing run-time linking would presumably make it slower. You'd probably want to make a trade-off between putting things in run-time libraries and in regular libraries. > > * executables are even SMALLER > > * You needn't link with large static libraries... or any at all. Again, for the sake of saving disk space, you probably want to make a tradeoff between putting stuff in these libraries and in regular compile-time libraries. You wouldn't, for example, necessarily put the entire ANSI C standard library in one of these things; it would take up a chunk of the Workbench disk with many functions never being used. > * by providing an interface to the original library types via this > new scheme, you would simply relink existing object with a > link-time library which *doesn't* contain the library routines to > make it work with the new libraries (assuming you have a new linker > which supports the new hunk type). Or you could implement the new scheme on top of the old library scheme, which would mean old object would remain compatible. This would probably be the ideal way to do it. The loader could allocate the library base vectors and open the libraries; there would be a new Exec call something like "close loaded libraries" which would be the compiler's responsibility to put in the exit() code, which would close all libraries opened by the loader (something like the MemList scheme which no one uses.) Old code would simply not call "close loaded libraries", and would close it's libraries manually. (Of course with resource tracking the compiler wouldn't have to do this. Resource tracking, please, please!? UnLoadSeg() or something would deallocate resources attached to the task, including libraries.) Another point: the new linker should also check the resultant executable to make sure unresolved function calls would actually be resolved by existing library functions (presumably the linker could get a list of names of library functions from Exec somehow). If the function would not be resolved in this fashion, then an unresolved linker error message should be printed. This is not really necessary, since the loader would do the same thing, but it would be a handy service (since the linker could provide more complete information about where the symbol was unresolved than the loader.) -Mitsu
dillon@CORY.BERKELEY.EDU.UUCP (06/06/87)
> What about load speed? AmigaDOS is already pretty slow at loading >executables, and doing run-time linking would presumably make it slower. >You'd probably want to make a trade-off between putting things in >run-time libraries and in regular libraries. Load speed isn't a problem. No relocation need be done at all, since all references have already been resolved to a single vector location (containing a jump instruction). Thus, you simply go linearly through the function-names list, find the vector, and stick it in the proper vector table slot. Assuming a hash based system-library-vector-names-list, you could have 500 DIFFERENT names and you still wouldn't notice the load lag. > Again, for the sake of saving disk space, you probably want to >make a tradeoff between putting stuff in these libraries and in regular >compile-time libraries. You wouldn't, for example, necessarily put >the entire ANSI C standard library in one of these things; it would >take up a chunk of the Workbench disk with many functions never being used. Well, for starters, you would want all the current library vectors in... for all the amiga libraries (they can still be disk based, with the code not necessarily loaded into RAM... the *system* still has a notion of vector groups). It would be nice if most of the C library were also implemented... perhaps those functions which do not depend on STDIO (like strcmp, etc...). Eventually, I would like to see STDIO comletely implemented. > Another point: the new linker should also check the resultant >executable to make sure unresolved function calls would actually be >resolved by existing library functions (presumably the linker could >get a list of names of library functions from Exec somehow). If the >function would not be resolved in this fashion, then an unresolved >linker error message should be printed. This is not really necessary, >since the loader would do the same thing, but it would be a handy >service (since the linker could provide more complete information >about where the symbol was unresolved than the loader.) Right, but since this would limit what you are linking to your current machine (either that, or have lots of namelists lying around), you want an option to disable it. ... better, make it a warning message only. The system will abort a LoadSeg() if it can't find a vector name. -Matt
grr@cbmvax.UUCP (06/07/87)
In article <8706060558.AA04607@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >(can somebody give me Dale's email address?). ...!pyramid!amiga!dale ...!oliveb!amiga!dale ...!cbmvax!amiga!dale -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jmsynge@sqm.dec.com.UUCP (06/07/87)
I'm glad Matt brought this idea up. I've been contemplating how this could be
built into the Amiga. The one system which I've used that had this form of
linkage (Prime's PRIMOS Operating System, apparently based on Multics) was
really great to use. The references were resolved the first time they were
used, not at image activation.
One difficulty with the scheme Matt mentioned: How does the library function
know where it's Library structure is? Currently, the non-shared libraries
(c.lib for Aztec users) contain glue routines which place this value in A6.
A suggestion: the new hunk type could define a table of 6 byte entries.
struct DynamicLinkage {
struct Library * dl_Library;
short int dl_LVO; /* Library Vector Offset */
}
dl_LVO would be a signed offset (always negative) which is the offset into the
library vector. This table could be constructed at run time by the loader.
This table would be used by the glue routines which would still need to be
provided, but the values would be resolved automatically. (Question: how
would the library be closed? Currently this must be done explicitly.)
Now you could have two types of run-time library references: those which
specify the name of a function (i.e. printf) and those which specify a library
name (exec.library). The latter could have the offset value prespecified.
This distinction could could be made during linkage.
A change would be also be needed to all the shared libraries: The would need
a way to tell loader which routines they contained. Perhaps one of the flag
bits (lib_Flags) in the Library structure could indicate that there was an
additional pointer at the end of the structure (lib_FunctionNames ?) which
pointed to a list of 6 byte entries.
struct LibraryFunctionEntry {
char * lfe_Name;
short int lfe_LVO;
}
Alternately, the library's initialization code could call a new exec function
in order to declare the names of the library's functions.
For efficiency it would probably be necessary for the loader to hash the
names so that image activation wouldn't be unbearably slow.
Those who have read this far will have gotten the idea that I think this is
a GREAT thing to do. It is! If you would like further info about some real
systems which use this, feel free send me email.
James Synge
USENET: {decvax, ucbvax, allegra}!decwrl!sqm.dec.com!jmsynge
ARPAnet: jmsynge%sqm.DEC@decwrl.DEC.COM
#include <disclaimer.h>
"Ken Olsen can speak for Digital, not me!"