ELF experts quiz:image dump with ELF

From: Johann Friedrich Heinrichmeyer <Fritz.Heinrichmeyer_at_FernUni-Hagen.de>
Date: Tue, 13 Jun 95 22:00:44 +0200

I recompiled the impressive STk interpreter (scheme interpreter with an
interface to the Tk from tclTk, scheme is a kind of "lisp-light"
powerful interpreter language which can define itself away :-) ) for ELF
dynamic linking and loading (dlopen and friends, almost out of the box).

Now i also wanted to dump an image of the data segments for later use
which now only works for some platforms. Whith the binary format "a.out"
under Linux and SunOS i had no problems. Also a statically linked ELF
binary works.

STk image dump works in principle the following way:

The interpreter saves its current status in a continuation variable on
the dynamic data segment ( a jmpbuf structure and data from the stack
mainly). Then the whole data segment (.data and .bss) is saved in a
file.

When the interpreter is called with -image <imagefile>. The whole data
segment is restored from the file and the "continuation" from the image
file is executed. Now we are at the point after the
(dump "filename_of_image")
from the previous run.

Why does it fail with dynamically linked ELF?

It works "a little", the continuation is restored and found by the
interpreter but after the first "longjmp" the program runs away. The
virtual addresses look the same. Which segment do i have handle
different? Maybe the jmpbuf structure is not complete for saving
environments of different processes?

I know i can read the gdb sources .... a pointer would help
anyway. Reading emacs sources may not help as there is no saved stack
involved i think ....

Fritz

-- 
Fritz Heinrichmeyer                             FernUniversitaet Hagen
FAX:   +49 2371/566236                          LG Elektronische Schaltungen
EMAIL: fritz.heinrichmeyer_at_fernuni-hagen.de     Frauenstuhlweg 31
PHONE: +49 02371/566-243                        58644 Iserlohn (Germany)
WWW:  http://ES-sun2.fernuni-hagen.de
Received on Tue Jun 13 1995 - 22:02:16 CEST

This archive was generated by hypermail 2.3.0 : Mon Jul 21 2014 - 19:38:59 CEST