aix.dump

早期freebsd实现

The following text was written by someone at IBM to describe an older
version of the code for dumping on AIX.

I couldn't understand the code, and I can't fully understand this text
either.  I rewrote the code to use the same basic principles, as far
as I understood them, but more cleanly.  It does not always work.

It seems that the IBM dumping code was simply set up to detect when
the dumped data cannot be used, and in that case to act approximately
as if CANNOT_DUMP had been defined all along.  (This is buried in
paragraph 1.)  It seems simpler just to define CANNOT_DUMP, since
Emacs is not set up to decide at run time whether there is dumping or
not, and doing so correctly would be a lot of work.

Note that much of the other information, such as the name and format 
of the dumped data file, has been changed.


		--rms



        A different approach has been taken to implement the
"dump/load" feature of GNU Emacs for AIX 3.1.  Traditionally the
unexec function creates a new a.out executable file which contains
preloaded Lisp code.  Executing the new a.out file (normally called
xemacs) provides rapid startup since the standard suite of Lisp code
is preloaded as part of the executable file.

        AIX 3.1 architecture precludes the use of this technique
because the dynamic loader cannot guarantee a fixed starting location
for the process data section.  The loader loads all shared library
data BEFORE process data.  When a shared library changes its data
space, the process initial data section address (_data) will change
and all global process variables are automatically relocated to new
addresses.  This invalidates the "dumped" Emacs executable which has
data addresses which are not relocatable and now corrupt.  Emacs would
fail to execute until rebuilt with the new libraries.

        To circumvent the dynamic loader feature of AIX 3.1, the dump process
has been modified as follows:

        1) A new executable file is NOT created.  Instead, both pure and
           impure data are saved by the dump function and automatically
           reloaded during process initialization.  If any of the saved data
           is unavailable or invalid, loadup.el will be automatically loaded.

        2) Pure data is defined as a shared memory segment and attached
           automatically as read-only data during initialization.  This
           allows the pure data to be a shared resource amoung all Emacs
           processes.  The shared memory segment size is PURESIZE bytes.
           If the shared memory segment is unavailable or invalid, a new
           shared memory segment is created and the impure data save file
           is destroyed, forcing loadup.el to be reloaded.

        3) The ipc key used to create and access Emacs shared memory is
           SHMKEY and can be overridden by the environment symbol EMACSSHMKEY.
           Only one ipc key is allowed per system.  The environment symbol
           is provided in case the default ipc key has already been used.

        4) Impure data is written to the ../bin/.emacs.data file by the
           dump function.  This file contains the process' impure data
           at the moment of load completion.  During Emacs initialization,
           the process' data section is expanded and overwritten
           with the .emacs.data file contents.

        The following are software notes concerning the GNU Emacs dump function under AIX 3.1:

        1) All of the new dump/load code is activated by the #ifdef SHMKEY
           conditional.

        2) The automatic loading of loadup.el does NOT cause the dump function
           to be performed.  Therefore once the pure/impure data is discarded,
           someone must remake Emacs to create the saved data files.  This
           should only be necessary when Emacs is first installed or whenever
           AIX is upgraded.

        3) Emacs will exit with an error if executed in a non-X environment
           and the dump function was performed within a X window.  Therefore
           the dump function should always be performed in a non-X
           environment unless the X environment will ALWAYS be available.

        4) Emacs only maintains the lower 24 bits of any data address.  The
           remaining upper 8 bits are reset by the XPNTR macro whenever any
           Lisp object is referenced.  This poses a serious problem because
           pure data is stored in segment 3 (shared memory) and impure data
           is stored in segment 2 (data).  To reset the upper 8 address bits
           correctly, XPNTR must guess as to which type of data is represented
           by the lower 24 address bits.  The technique chosen is based upon
           the fact that pure data offsets in segment 3 range from
           0 -> PURESIZE-1, which are relatively small offsets.  Impure data
           offsets in segment 2 are relatively large (> 0x40000) because they
           must follow all shared library data.  Therefore XPNTR adds segment
           3 to each data offset which is small (below PURESIZE) and adds
           segment 2 to all other offsets.  This algorithm will remain valid
           as long as a) pure data size remains relatively small and b) process
           data is loaded after shared library data.

           To eliminate this guessing game, Emacs must preserve the 32-bit
           address and add additional data object overhead for the object type
           and garbage collection mark bit.

        5) The data section written to .emacs.data is divided into three
           areas as shown below.  The file header contains four character
           pointers which are used during automatic data loading.  The file's
           contents will only be used if the first three addresses match
           their counterparts in the current process.  The fourth address is
           the new data segment address required to hold all of the preloaded
           data.


                        .emacs.data file format

                +---------------------------------------+ \
                |     address of _data                  |  \
                +---------------------------------------+   \
                |     address of _end                   |    \
                +---------------------------------------+      file header
                |     address of initial sbrk(0)        |    /
                +---------------------------------------+   /
                |     address of final sbrk(0)          |  /
                +---------------------------------------+ /
                \                                       \
                \                                       \
                      all data to be loaded from
                      _data to _end
                \                                       \
                \                                       \
                +---------------------------------------+
                \                                       \
                \                                       \
                      all data to be loaded from
                      initial to final sbrk(0)
                \                                       \
                +---------------------------------------+


           Sections two and three contain the preloaded data which is
           resotred at locations _data and initial sbrk(0) respectively.

           The reason two separate sections are needed is that process
           initialization allocates data (via malloc) prior to main()
           being called.  Therefore _end is several kbytes lower than
           the address returned by an initial sbrk(0).  This creates a
           hole in the process data space and malloc will abort if this
           region is overwritten during the load function.

           One further complication with the malloc'd space is that it
           is partially empty and must be "consumed" so that data space
           malloc'd in the future is not assigned to this region.  The malloc
           function distributed with Emacs anticipates this problem but the
           AIX 3.1 version does not.  Therefore, repeated malloc calls are
           needed to exhaust this initial malloc space.  How do you know
           when malloc has exhausted its free memroy? You don't!  So the
           code must repeatedly call malloc for each buffer size and
           detect when a new memory page has been allocated.  Once the new
           memory page is allocated, you can calculate the number of free
           buffers in that page and request exactly that many more.  Future
           malloc requests will now be added at the top of a new memory page.

           One final point - the initial sbrk(0) is the value of sbrk(0)
           after all of the above malloc hacking has been performed.


        The following Emacs dump/load issues need to be addressed:

        1) Loadup.el exits with an error message because the xemacs and
           emacs-xxx files are not created during the dump function.

           Loadup.el should be changed to check for the new .emacs.data
           file.

        2) Dump will only support one .emacs.data file for the entire
           system.  This precludes the ability to allow each user to
           define his/her own "dumped" Emacs.

           Add an environment symbol to override the default .emacs.data
           path.

        3) An error message "error in init file" is displayed out of
           startup.el when the dumped Emacs is invoked by a non-root user.
           Although all of the preloaded Lisp code is present, the important
           purify-flag has not been set back to Qnil - precluding the
           loading of any further Lisp code until the flag is manually
           reset.

           The problem appears to be an access violation which will go
           away if the read-write access modes to all of the files are
           changed to rw-.

        4) In general, all file access modes should be changed from
           rw-r--r-- to rw-rw-rw-.  They are currently setup to match
           standard AIX access modes.

        5) The dump function is not invoked when the automatic load of
           loadup.el is performed.

           Perhaps the command arguments array should be expanded with
           "dump" added to force an automatic dump.

        6) The automatic initialization function alloc_shm will delete
           the shared memory segment and .emacs.data file if the "dump"
           command argument is found in ANY argument position.  The
           dump function will only take place in loadup.el if "dump"
           is the third or fourth command argument.

           Change alloc_shm to live by loadup.el rules.