This is the mail archive of the guile@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] |
Andrew Archibald <aarchiba@calum.csclub.uwaterloo.ca> writes: > John Tobey <jtobey@channel1.com> writes: > > > This confused me too when I first heard it claimed, "unexec and shared > > libs don't mix". I think he means that you can't create a dynamic > > library from a heap image, an assertion which I still dispute. > > Well, the current state of affairs with guile-unexec is that when > memory is dumped, there must be no dynamically-linked code in use, > because when the executable is pulled off disk, any atempt to > reference anything in the dynamic library produces a segfault. This > was observed on GNU/Linux with libc5. This is a pain; I don't know if > it can be fixed in general. The Condor guys concluded the same for checkpointing programs, which is basically the same as unexec. They concluded that the only thing to do was to dump all of the memory mapped segments & map them back in at the appropriate places when running the checkpointed program. In general I'd expect all sorts of cross pointers between the mmapped segments. Many of the mmapped segments come from the shared libraries. They can get mapped differently for each invocation of the program. You'll get fcn call & data cross pointers just from the loading in of the shared libraries. Malloc gives additional cross pointers becuase many implementations use mmap instead of sbrk. Not to mention the fact that the shared library itself can have internal pointers. I think you'd be much better off in the short term & in the long run to get hobbit working to the point where it can easily & reliably compile the modules into shared libraries. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il