gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: Dynamic Library Linking


From: Camm Maguire
Subject: [Gcl-devel] Re: Dynamic Library Linking
Date: 05 May 2005 15:02:10 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

"Mike Thomas" <address@hidden> writes:

> Hi Camm.
> 
> | This is indeed the short answer -- you can link in any new symbols you
> | want that are not present in the original image via compiler::link.
> | See the documentation for this function in gcl-si.{texi,info}.  What
> | this essentially does is build a new gcl image using a fresh call to
> | the system linker ld to modify the image symbol table with whatever
> | new code or libraries you specify.  It has the disadvantage that the
> | image is 'fresh' -- i.e. any work you may have done in the running
> | image before compiling compiler::link is lost.  Such work can be
> | respecified to run by hand in the fresh new image through one of
> | compiler::link's arguments, but this is a bit awkward to use.
> |
> | What I'd like to do in 2.7.0 is to allow the user to link in new
> | dynamic libraries at runtime, modify the running image's symbol table,
> | and allow this work to be preserved across image saves via
> | si::save-system.  What this essentially means is that unexec needs to
> | add a little section to the end of the dumped image containing
> | relocation records for the new symbols for use by the system's dynamic
> | linker (ld.so on Linux), i.e. a GOT (Global Access Table).
> 
> If I understand you correctly, on Windows one could store the name of the
> symbol and the name of the DLL from whence it came, then while resolving
> references at ru(i)ntime to call LoadLibrary() and GetProcAddress() for each
> pair as shown here:
> 
>    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/
> base/using_run_time_dynamic_linking.asp
> 
> I believe that PE-COFF executables actually have a section for external
> library references (ie references to DLL's) into which unexec might put this
> kind of information so that the OS could automatically do the external
> relocation work at image load time (though probably only for those
> relocation records in the text sections I guess) .  This is all pretty hairy
> though, especially as Windows moves towards 64 bits and whatever system
> changes might come with that.
> 

This is exactly the idea.  When we have time :-).

Take care,


> | A kludgy way of doing this without any special executable format
> | knowledge might be to expand the explicit C plt table (mplt in plt.c)
> | with a bunch of dummy entries referring to unused symbols in external
> | shared libs, one of which we might provide for this purpose.  Then
> | when new symbols are needed, these symbols could be changed.  This
> | would still require us to be able to find the symbol in the image's
> | symbol table, but at least we would not have to add any new sections,
> | etc.  Of course this approach is rather awkward and limited too.
> 
> It all sounds awkward to me as I'm pretty vague on all of this.
> 
> Cheers
> 
> Mike Thomas.
> 
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]