[image of the Ego + Pego logo ] [ English | Esperanto | Français ]
Introduction to Ego

Introduction to Pego


Source Code

Related Links


What is it?

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.

Introduction to Ego, a C/C++ Introspection Library

Ego is a free 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 ;))...

Introduction to Pego, a C Portable Checkpointing Library

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

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 | PDF | PS ]
  • Documentation for Pego, the portable state capture library: [ HTML | PDF | PS ].
  • Overhead transparencies of the Libre Software Meeting 2003 talk: [ PS | PDF | Lout ]
  • Master's report (in French, rapport de DEA, see abstract on the last page) : [ PS | PDF | Lout ]

Source Code

Ego and Pego are free 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 debugging information.
  • 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 (updated daily).
  • 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 `kill -HUP' 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 PocketKobo website. 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.

Warning! On x86, one test from Ego's testsuite (the `symbol-hierarchy' 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 `-g'). Everything should work perfectly fine when using GCC 2.95.4.

Related Links

  • The Tui Heterogeneous 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.
  • The 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.
  • The 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 support library".
  • Libckpt, a well-known binary checkpointing library for Unix-like systems.
  • The "Stab" Debug Format describes the stabs debug format as used by GCC.
  • 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 group.

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. ;-)

Please send questions to Ludovic Courtès, <lcourtes -at- altern.org>.

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

Updated: Thu Jan 22 14:08:28 CET 2004