emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs cannot dump on GNUstep


From: Adrian Robert
Subject: Re: Emacs cannot dump on GNUstep
Date: Wed, 12 Nov 2008 15:27:48 -0500

Hi,

The previous email is about this problem of Emacs.app not working when dumped under GNUstep. Since I cannot work on this myself at the moment (and failed when I *did* put time into it before), let me provide the background of what I know. What happens is this: emacs loads into memory, then performs a bunch of initialization (mainly reading/interpreting elisp files), then dumps its in-memory executable +data image out to disk. In the future, this becomes the new executable, the idea being that you then are up and running without having to perform the initialization.

Something in this causes a failure under GNUstep (trace below). I'm not sure if it's a problem with the emacs dump code or with initialization in the GNUstep runtime, but I think there is some more that can be tried on the emacs side codewise, though it would be best done by someone acquainted with GNUstep memory handling.

The thing to look at is the difference between unexmacosx.c and, e.g., unexelf.c. It seems that some special handling for memory allocation may be needed. In unexmacosx, we read in the comments:

   The Mac OS X implementation of unexec makes use of Darwin's `zone'
   memory allocator.  All calls to malloc, realloc, and free in Emacs
   are redirected to unexec_malloc, unexec_realloc, and unexec_free in
   this file.  When temacs is run, all memory requests are handled in
   the zone EmacsZone.  The Darwin memory allocator library calls
   maintain the data structures to manage this zone.  Dumping writes
   its contents to data segments of the executable file.  When emacs
   is run, the loader recreates the contents of the zone in memory.
   However since the initialization routine of the zone memory
   allocator is run again, this `zone' can no longer be used as a
   heap.  That is why emacs uses the ordinary malloc system call to
   allocate memory.  Also, when a block of memory needs to be
   reallocated and the new size is larger than the old one, a new
   block must be obtained by malloc and the old contents copied to
   it.

It is possible that adding this sort of logic to unexelf will solve the problem. Note there are also some #defines in darwin.h that would need to be replicated in gnu-linux.h or whatever system is being compiled on. Because emacs plays a number of games with malloc on different systems (search for "Doug Leah" in the code and configure scripts) there may be more to be done than straight copy-paste.

If there is still a failure after this is tried, there may be a gnu- apple difference in the runtime or how the foundation library initializes. But we can't be sure about this until unexelf under GNUstep does everything that unexmacosx does.


-Adrian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]