Re: Unexec gurus?

["Greg J. Badros" <gjb at cs dot washington dot edu>]

Sorry to follow up to my own post, but:

"Greg J. Badros" <gjb@cs.washington.edu> writes:

> Russell McManus <russell.mcmanus@msdw.com> writes:
> 
> > "Greg J. Badros" <gjb@cs.washington.edu> writes:
> > 
<snip>

> > Are you statically linking in libguile.a?  I know it's a simple one,
> > but it got me in the past.  If your dynamically linking libguile.so,
> > that variable gets whacked.  My memory here is fuzzy, I hope this
> > helps.
> 
> I had that thought too, but no, I'm not statically linking to libguile,
> but neither is tguile (but read below for more):
> 
> % ldd tguile
>         libguile.so.6 => /usr/lib/libguile.so.6 (0x4001a000)
<snip>
> 
> % ldd dumped_tguile
> < same as above, for ldd tguile >
> 
> % ldd scwm
<snip>
>         libguile.so.6 => /usr/lib/libguile.so.6 (0x40110000)
<snip>
> % ldd dumped_scwm
> < same as above, for ldd scwm >
> 
> BUT: because you suggested it, too, I decided to do the obvious
> experiment, and I linked scwm statically against libguile.a (instead of
> -lguile in the libtool link line).  My simple test succeeded there!
> 
> 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.  

Thanks again, Russ, for your help!

Greg