Introduction to Ego
Introduction to Pego
Ego and Pego are two C
libraries: Ego allows for C/C++ programs introspection, while Pego allows for
portable state capture of C/C++ applications. This is currently an `alpha'
release. Latest releases are Ego 0.1 and Pego 0.3.
Ego is a
program introspection library released under the terms of the
GNU General Public Licence.
C does not provide any introspection (reflective)
facilities, ie. facilities that allow to get information about the program at
run-time and to answer questions such as: What symbols are defined and what
are their types? What is the type of the data available at this address?
What is the function which called me? Ego aims at providing some of these
facilities to the application programmer, by using the debugging information
added to binary object files by the compiler. In other words, Ego is pretty
much like an embedded debugger, with limited functionalities (eg. no
breakpoints), but with maximum information made available to the user.
The main purpose of Ego is to permit the implementation of Pego (Portable &
Persistent Ego), a free program serialization library that can create portable
checkpoints of the application data. Note that this could also be used, for
instance, to write an automatic serialization library that could be used
within a "software bus" à la CORBA, or just a debugger (well, we already have
GDB so that would not be so useful ;))...
Pego is a
free serialization or
portable checkpointing library for C/C++ programs ("Pego" means "Portable
& Persistent Ego"), released under the terms of the GNU General Public
Pego aims at making data serialization easy and almost automagic for C/C++
programs. It uses Ego program introspection facilities in order to know what
has to be checkpointed (which symbols) and how (what types) which in turns
uses the information contained in the stabs debugging information. Pego can
produce XML files, files in a portable binary format, or it can even send
binary data over the network, each of which represents (part of) the state of
a program (here is an example of a portable
checkpoint made by Pego using libxml2,
and here is an equivalent portable checkpoint
created using Pego's binary storage backend). This state data can then be
loaded by the application in order to restore a previous state.
In short: Pego makes it possible to write persistent and migratable
applications with little tuning of the code.
- Documentation for Ego, the C instrospection library:
[ HTML |
- Documentation for Pego, the portable state capture library:
| PS ].
- Overhead transparencies of the
Libre Software Meeting
[ PS |
- Master's report (in French, rapport de DEA, see abstract on the
last page) : [ PS |
Ego and Pego are
software, released under the terms of the
GNU General Public Licence.
- Ego 0.1, the latest & greatest & first
version of Ego. Please note that this is an `alpha' release so it
may be buggy or miss features (see the `BUGS' files).
- Guile-Ego 0.1 (Sept. 9, 2003) is a
Guile module which offers
Scheme bindings to Ego. The package comes with two utility examples : one that
pretty prints the symbols contained in a binary file, and one that generates
source code for an interposition library from a binary file containing
Pego 0.3 (July 28, 2003) offers, among
other things, performance improvements compared to version 0.2. See the `NEWS'
file for details.
Pego 0.2 (July 4, 2003) : compared to
version 0.1 (first version ever) which
supported only XML input/output, it includes support for modular storage
backends. In particular, it includes and portable binary format backend, as
well as a network backend which allows for transferring/receiving state
captures directly through the network (see the
manual for further details).
If you have troubles with these versions, you may want to try out the
latest snapshot of Ego and Pego
- Persistent version of xGalaga 2.0 that
uses Pego in order to checkpoint its state each time the 'p' (for 'pause')
button is pressed during the game. You can also `
the process to force it to capture its state. When launched with the
-restore' option, xGalaga will restore its state from the last
checkpoint it made (see screenshot
of the persistent version of xGalaga. :-)).
This second screenshot shows three machines
running xGalaga with the exact same state (a PowerMac, an x86, and an old
SPARCStation 4, all of them running GNU/Linux). Note that the `pause'
picture doesn't appear at the same level on each replication which is normal
since it continued moving up and down after the state had been restored.
- Persistent version of XKobo,
a video game written in C++. The original version was developped by
Akira Higuchi and enhanced by
Wolfgang Jährling, see the
In order to get an idea of how much work was needed to make it persistent, you
can have a look at this diff file.
Note that you should use G++ 2.95 for Ego to work.
On x86, one test from Ego's testsuite (the `
test) may fail. However, this bug does not affect the facilities needed by
Pego. Keep in mind that any application that uses Pego should work fine with
GCC up to version 3.2 (maybe 3.3 ?), provided GNU stabs are produced,
using the `
-gstabs+', (not just `
Everything should work perfectly fine when using GCC 2.95.4.
Process Migration System
uses the same approach as Pego : it reads debugging information from the
program to be checkpointed in order to be able to actually checkpoint it in a
portable way. However, it is entirely dedicated to state capture (while Ego
could be used for other things), it is built on a customized version of the
Amsterdam Compiler Kit (ACK), and source code is not available.
Texas Persistent Store also uses debugging information in order to produce
so-called Run-Time Type Descriptors (RTTD) that are used to produce
portable checkpoints for C++ programs. Source code based on GDB is available
from this FTP server.
- The PORCH compiler is a
dedicated source-to-source compiler that adds useful infomation and code to
perform portable checkpoints. The
Process Introspection Projet uses a similar approach.
CORBA Persistent State Service (PSS) is about making CORBA applications
data persistent and portable. It requires the user to either write a PSDL
file (Persistent State Description Language) describing what data needs
to be persistent or use an open-compiler to automatize this step.
- Open compilers such as OpenC++allow for any kind of
source-to-source translation to be performed before the program is actually
compiled. See also
Marco's papers describing how OpenC++ can be used to make C++ applications
checkpointable in a portable way.
- The Introspector Project
aims at building a set of tools to extract and manipulate programs
meta-data. For C programs, it uses a modified GCC compiler that can
directly produce a program description file.
- Libcwd is a C++ "debugging
a well-known binary checkpointing library for Unix-like systems.
The "Stab" Debug Format describes the stabs debug format as used by
- The DWARF Debugging
Information Format is a rich debugging information format not (yet)
supported by Ego. It contains additional information such as call frames
information: "DWARF supports virtual unwinding by defining an architecture
independent basis for recording how procedures save and restore registers
throughout their lifetimes.". This format is also supported by
GCC on most platforms.
This work was performed at LAAS-CNRS in the
Dependable Computing and Fault Tolerance
The design of these webpages was greatly inspired by the
GNU Hurd webpages.
Many thanks to the GNU Hurd people for having nice webpages and also
for building such a cool operating system. ;-)