Re: Unexec gurus?

[Russell McManus <russell dot mcmanus at msdw dot com>]

"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.  

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

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

-russ

--
Face it, Bill Gates is a Persian cat and a monocle away from being
a villain in a James Bond movie.
             -- Dennis Miller