[Top][All Lists]
[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
- [Gcl-devel] Re: Dynamic Library Linking,
Camm Maguire <=