From Msim

Jump to: navigation, search

EIO_4 refers to the new EIO file version supported by M-Sim_3.0. EIO_3 will continue to be supported as EIO_4 should be considered an extension of the EIO_3 format and not a replacement.



The primary rationale for EIO_4 is to provide the ability to restore open file descriptors to a checkpointed thread. This came about originally from a problem within the SPEC2K benchmark crafty. Crafty allows user interrupts but acquires information about the terminal only during initialization. The simpoints checkpoint of crafty provides crafty stdin as file descriptor 0 which then begins accepting input and causes the execution to fail - in simplescalar, a syscall trace was added to the EIO files however, this limited execution up to the number of syscalls in the trace - preventing program completion.


An EIO_4 file is required to indicate its version at 4. All additional checkpoint components are added at the end of the checkpoint file (relative to EIO_3 without a syscall trace).


The format of the extensions is not yet finalized.

File Descriptor Table

This table is derived from translation_table and name_table contained within the context object. All threads must possess an entry for stdin, stdout and stderr.
An entry within this table contains the following:

  • File Descriptor value as seen by the thread
  • File Descriptor value as seen by the simulator
  • Current Seek value for the File Descriptor
  • Open Flags such as read, write.
  • Filename (or stdin, stdout, stderr - this means that if those filenames are used by the thread we have a problem).

For example:


The file descriptor as seen by the simulator may not be the same once loaded. In fact, we probably don't need to retain that value.

File Locations

All files that are opened need to be made available to the thread for use but must not be changed. This table indicates which files included with the checkpoint need to be used as source files and which source file they are. Files from this list are copied to the location expected by the thread.

  • Source filename
  • Target filename

For example:

{eio_file_1, thread.input,
 eio_file_2, thread.output,
 eio_file_3, thread.data}

Other Thread Table

Multiple threads can be included in a checkpoint. Only the first checkpoint file indicates the filenames of the other threads.

  • Thread checkpoint name

For example:


Checkpoint Generation

EIO_3 and EIO_4 are initially generated in almost the same fashion (EIO_4 reports file version 4 instead of 3, see bolded portion):

                       std::string input = eio_destination_filename;
                       std::ofstream outfile(input.c_str());
                               outfile << "/* This is a SimpleScalar EIO file - DO NOT MOVE OR EDIT THIS LINE! */\n" << std::endl;
                               outfile << "/* file_format: 2, file_version: 3, big_endian: 0 */\n(2, 3, 0)\n" << std::endl;
                               outfile << "/* ** start checkpoint @ -1... */\n" << std::endl;
                               outfile << "/* EIO file pointer: -1... */\n18446744073709551615\n" << std::endl;
                               outfile << contexts[0].regs;
                               outfile << contexts[0].mem;
                               std::cout << "Failed opening output file, ignoring request" << std::endl;

The checkpoint always starts with the first thread. Cores are not retained in a checkpoint since the threads are mobile. EIO_4 support is added immediately before outfile.close() and after writing of the context's memory space.

Personal tools