This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Unexec gurus?


>>>>> "Russell" == Russell McManus <russell.mcmanus@msdw.com> writes:

    Russell> "Greg J. Badros" <gjb@cs.washington.edu> writes:
    >> > What gives?  Why can tguile get away with dynamically linking
    >> against > libguile.so, but my scwm test case cannot?
    >> 
    >> Upon closer inspection of the linking of tguile, I observed
    >> that it does, in fact, include libguile.a in its link line
    >> *before* the -lguile entry.  The -lguile entry is thus
    >> superfluous (assuming the .a matches the .so) but results in
    >> ldd listing libguile among tguile's shared object dependences.
    >> 
    >> The moral of the story:
    >> 
    >> do not trust that just because a .so is listed in ldd output
    >> that the code of that .so is *not* statically linked.
    >> Re-inspect the link lines instead to determine what's going on.
    >> 
    >> Now my question becomes: is it a fundamental weakness of
    >> unexec/dump that all code must be statically linked in order to
    >> preserve state?  This seems a little counterintuitive because
    >> I'd've thought that the data segments could still be preserved.

    Russell> I learned everything I know about unexec by trying stuff
    Russell> and seeing what works.  So I'm no expert here, but I'll
    Russell> share my theory anyway.

    Russell> I think that the problem is that the pre-dumped binary
    Russell> records some information that it needs libguile.so.  Then
    Russell> the dumped image records the same fact, along with all
    Russell> the information that appeared in libguile.so.  When the
    Russell> dumped image gets reloaded, even though the image already
    Russell> has everything it needs from libguile.so, the dynamic
    Russell> linker thinks it needs to do a dynamic link of
    Russell> libguile.so.  So it links in libguile.so again, and
    Russell> whacks what was dumped.  Sorry for using such technically
    Russell> advanced jargon.  ;^) Bernard probably has a better
    Russell> understanding.

I am just jumping in this thread...
Actually I had the same prctical experience with unexec 
when building tguile, and you interpretation of the 
behaviour of static variables when dyn-linking is right. 
One more mystery of unexec solved !

One more thing to do is to extend unexec for HP-UX. 
Unexec works for HP-UX, but you cannot load new dynamic 
code in a dumped executable. This is
so because the dumped executable does not save some adresses
which are needed by dynamically loaded code. All this information is
publicized in "HP-UX Reference Release 10.0" (a set of 4 volumes).
I have the books, but not any time to dig into this problem.

So if someone else has the time to try...

Regards.

-- 

B. Urban

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]