Next: , Up: A Summary of the Various SXEmacs Modules   [Contents][Index]

10.1 Low-Level Modules


This is automatically generated from based on the results of configure tests and user-selected optional features and contains preprocessor definitions specifying the nature of the environment in which SXEmacs is being compiled.


This is automatically generated from based on supplied configure values, and allows for non-standard installed configurations of the SXEmacs directories. It’s currently broken, though.


emacs.c contains main() and other code that performs the most basic environment initializations and handles shutting down the SXEmacs process (this includes kill-emacs, the normal way that SXEmacs is exited; dump-emacs, which is used during the build process to write out the SXEmacs executable; run-emacs-from-temacs, which can be used to start SXEmacs directly when temacs has finished loading all the Lisp code; and emergency code to handle crashes [SXEmacs tries to auto-save all files before it crashes]).

Low-level code that directly interacts with the Unix signal mechanism, however, is in signal.c. Note that this code does not handle system dependencies in interfacing to signals; that is handled using the syssignal.h header file, described in section J below.


These modules contain code dumping out the SXEmacs executable on various different systems. (This process is highly machine-specific and requires intimate knowledge of the executable format and the memory map of the process.) Only one of these modules is actually used; this is chosen by configure.


These modules are used in conjunction with the dump mechanism. On some systems, an alternative version of the C startup code (the actual code that receives control from the operating system when the process is started, and which calls main()) is required so that the dumping process works properly; crt0.c provides this.

pre-crt0.c and lastfile.c should be the very first and very last file linked, respectively. (Actually, this is not really true. lastfile.c should be after all Emacs modules whose initialized data should be made constant, and before all other Emacs files and all libraries. In particular, the allocation modules gmalloc.c, alloca.c, etc. are normally placed past lastfile.c, and all of the files that implement Xt widget classes must be placed after lastfile.c because they contain various structures that must be statically initialized and into which Xt writes at various times.) pre-crt0.c and lastfile.c contain exported symbols that are used to determine the start and end of SXEmacs’ initialized data space when dumping.


These handle basic C allocation of memory. alloca.c is an emulation of the stack allocation function alloca() on machines that lack this. (SXEmacs makes extensive use of alloca() in its code.)

gmalloc.c and malloc.c are two implementations of the standard C functions malloc(), realloc() and free(). They are often used in place of the standard system-provided malloc() because they usually provide a much faster implementation, at the expense of additional memory use. gmalloc.c is a newer implementation that is much more memory-efficient for large allocations than malloc.c, and should always be preferred if it works. (At one point, gmalloc.c didn’t work on some systems where malloc.c worked; but this should be fixed now.)

ralloc.c is the relocating allocator. It provides functions similar to malloc(), realloc() and free() that allocate memory that can be dynamically relocated in memory. The advantage of this is that allocated memory can be shuffled around to place all the free memory at the end of the heap, and the heap can then be shrunk, releasing the memory back to the operating system. The use of this can be controlled with the configure option --rel-alloc; if enabled, memory allocated for buffers will be relocatable, so that if a very large file is visited and the buffer is later killed, the memory can be released to the operating system. (The disadvantage of this mechanism is that it can be very slow. On systems with the mmap() system call, the SXEmacs version of ralloc.c uses this to move memory around without actually having to block-copy it, which can speed things up; but it can still cause noticeable performance degradation.)

free-hook.c contains some debugging functions for checking for invalid arguments to free().

vm-limit.c contains some functions that warn the user when memory is getting low. These are callback functions that are called by gmalloc.c and malloc.c at appropriate times.

getpagesize.h provides a uniform interface for retrieving the size of a page in virtual memory. mem-limits.h provides a uniform interface for retrieving the total amount of available virtual memory. Both are similar in spirit to the sys*.h files described in section J, below.


These implement a couple of basic C data types to facilitate memory allocation. The Blocktype type efficiently manages the allocation of fixed-size blocks by minimizing the number of times that malloc() and free() are called. It allocates memory in large chunks, subdivides the chunks into blocks of the proper size, and returns the blocks as requested. When blocks are freed, they are placed onto a linked list, so they can be efficiently reused. This data type is not much used in SXEmacs currently, because it’s a fairly new addition.

The Dynarr type implements a dynamic array, which is similar to a standard C array but has no fixed limit on the number of elements it can contain. Dynamic arrays can hold elements of any type, and when you add a new element, the array automatically resizes itself if it isn’t big enough. Dynarrs are extensively used in the redisplay mechanism.


This module is used in connection with inline functions (available in some compilers). Often, inline functions need to have a corresponding non-inline function that does the same thing. This module is where they reside. It contains no actual code, but defines some special flags that cause inline functions defined in header files to be rendered as actual functions. It then includes all header files that contain any inline function definitions, so that each one gets a real function equivalent.


These functions provide a system for doing internal consistency checks during code development. This system is not currently used; instead the simpler assert() macro is used along with the various checks provided by the ‘--error-check-*’ configuration options.


This is not currently used.

Next: , Up: A Summary of the Various SXEmacs Modules   [Contents][Index]