mwherman@watcgl.UUCP (Michael W. Herman) (04/10/85)
Check net.sources from about 6 months ago. PADPowell@wateng had posted some code he developed (twice actually). I have an improved version of his code that I'm not ready to distribute just yet. On the subject of efficiency ... I would like to know if anyone else is using Pat's code and has attempted to speed up the dynamic loading. My quasi- quantitative analysis shows it takes from 10-40 seconds of elapsed time to dynamically load ~10 Kbytes of code image. Of the total, about 2 seconds of elapsed time is needed to invoke *ld* (regardless of whether you use *system()* or *vfork* and *execv*). Most of the rest of time is spent in *ld* itself. About 25% of this time is spent in the *read* system call reading libraries (which, in my application, are quite large (~500 Kbytes) and yes, compiled with cc -g ...). *ld* seems to be doing a lot of optimization of the i/o already so I don't expect to be able to speed *ld* up. However, I expect things to speed up quite a bit when I drop -g. I would like to try eliminating the 2 seconds needed to invoke *ld* by loading it into the program at "compile-time" and calling it directly as an ordinary C function (or I suppose I really should be dynamically loading it ;-) ). This would involve turning the *ld* program into a function (mostly just a name change and the problem compile-time initialization of static variables). If anyone has done this, plse let me know. On the subject of *dbx* ... At the moment a lot of my code has been compiled with -g to leave the extra symbol table info lying around for *dbx*. It would be nice to be able to have this information preserved in the dynamically loaded code as well. I haven't had any luck in trying to achieve this. Apparently, it is the C compiler that causes this info to remain when an executable code image is created by *ld* and *ld* is passive in this regard (It just does the loading including the forced loading of -lg (because it really just a .o file masquerading as a .a library).) I've tried using *cc -A ...* instead of *ld -A ...* to create the code image to be but get all sorts of "multiply defined" msgs from *ld*. Plse let me know if you have any suggestions that might help solve this last point. Michael Herman Computer Graphics Laboratory Department of Computer Science University of Waterloo Waterloo, Ontario, Canada N2L 3G1 UUCP: {allegra,ihnp4,watmath}!watcgl!mwherman -or- {cbosgd,clyde,decvax,linus,tektronix,utcsrgv}!watmath!watcgl!mwherman CSNET: mwherman%watcgl@waterloo.CSNET ARPA: mwherman%watcgl%waterloo.CSNET@csnet-relay.ARPA
chris@umcp-cs.UUCP (Chris Torek) (04/12/85)
Keeping the -g symbol table in dynamically loaded object modules is no problem: ld already writes a new symbol table (indeed, the dynamic loading code requires it) and does not strip the debugger entries. The trick is convincing dbx to look in two different places for the object code and for the symbol table. I imagine kludging up an extra dbx argument to read the new symbol table wouldn't be too difficult (then again I haven't looked at the dbx source, not needing a debugger :-)). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland