From 37300ce6c34202d1074dc19709aabd0bb74adc25 Mon Sep 17 00:00:00 2001 From: Pip Cet Date: Wed, 21 Aug 2024 08:45:13 +0000 Subject: [PATCH] Unexec removal: Documentation adjustments * doc/lispref/internals.texi (Building Emacs): * doc/lispref/os.texi (Command-Line Arguments): Remove documentation for 'unexec'-specific code and arguments. * etc/PROBLEMS: Remove unexec-specific problems. (cherry picked from commit 0e37b11e659dd58c520d557820b006a8d03c71e6) --- doc/lispref/internals.texi | 28 ------------ doc/lispref/os.texi | 8 ++-- etc/PROBLEMS | 90 -------------------------------------- 3 files changed, 4 insertions(+), 122 deletions(-) diff --git a/doc/lispref/internals.texi b/doc/lispref/internals.texi index 63c1761d72b..be987e1f977 100644 --- a/doc/lispref/internals.texi +++ b/doc/lispref/internals.texi @@ -76,23 +76,6 @@ Like @samp{pdump}, but used while @dfn{bootstrapping} Emacs, when no previous Emacs binary and no @file{*.elc} byte-compiled Lisp files are available. The produced dump file is usually named @file{bootstrap-emacs.pdmp} in this case. - -@item dump -@cindex unexec -This method causes @command{temacs} to dump out an executable program, -called @file{emacs}, which has all the standard Lisp files already -preloaded into it. (The @samp{-batch} argument prevents -@command{temacs} from trying to initialize any of its data on the -terminal, so that the tables of terminal information are empty in the -dumped Emacs.) This method is also known as @dfn{unexec}, because it -produces a program file from a running process, and thus is in some -sense the opposite of executing a program to start a process. -Although this method was the way that Emacs traditionally saved its -state, it is now deprecated. - -@item bootstrap -Like @samp{dump}, but used when bootstrapping Emacs with the -@code{unexec} method. @end table @cindex preloaded Lisp files @@ -227,17 +210,6 @@ that problem, you can put functions on the Emacs. @end defun -@defun dump-emacs to-file from-file -@cindex unexec -This function dumps the current state of Emacs into an executable file -@var{to-file}, using the @code{unexec} method. It takes symbols from -@var{from-file} (this is normally the executable file @file{temacs}). - -This function cannot be used in an Emacs that was already dumped. -This function is deprecated, and by default Emacs is built without -@code{unexec} support so this function is not available. -@end defun - @defun pdumper-stats If the current Emacs session restored its state from a dump file, this function returns information about the dump file and the diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi index e28b150ad73..6f1bb000a6b 100644 --- a/doc/lispref/os.texi +++ b/doc/lispref/os.texi @@ -590,10 +590,10 @@ displays the startup messages. The value of this variable is @code{t} once the command line has been processed. -If you redump Emacs by calling @code{dump-emacs} (@pxref{Building -Emacs}), you may wish to set this variable to @code{nil} first in -order to cause the new dumped Emacs to process its new command-line -arguments. +If you redump Emacs by calling @code{dump-emacs-portable} +(@pxref{Building Emacs}), you may wish to set this variable to +@code{nil} first in order to cause the new dumped Emacs to process its +new command-line arguments. @end defvar @defvar command-switch-alist diff --git a/etc/PROBLEMS b/etc/PROBLEMS index c9a208518d2..ee72a04f493 100644 --- a/etc/PROBLEMS +++ b/etc/PROBLEMS @@ -2952,20 +2952,6 @@ This was observed for Emacs 28.1 on Solaris 10 32-bit sparc, with Oracle Developer Studio 12.6 (Sun C 5.15). The failure was intermittent, and running GNU Make a second time would typically finish the build. -*** On Solaris 10, Emacs crashes during the build process. -(This applies only with './configure --with-unexec=yes', which is rare.) -This was reported for Emacs 25.2 on i386-pc-solaris2.10 with Sun -Studio 12 (Sun C 5.9) and with Oracle Developer Studio 12.6 (Sun C -5.15), and intermittently for sparc-sun-solaris2.10 with Oracle -Developer Studio 12.5 (Sun C 5.14). Disabling compiler optimization -seems to fix the bug, as does upgrading the Solaris 10 operating -system to Update 11. The cause of the bug is unknown: it may be that -Emacs's archaic memory-allocation scheme is not compatible with -slightly-older versions of Solaris and/or Oracle Studio, or it may be -something else. Since the cause is not known, possibly the bug is -still present in newer versions of Emacs, Oracle Studio, and/or -Solaris. See Bug#26638. - *** On Solaris, C-x doesn't get through to Emacs when you use the console. This is a Solaris feature (at least on Intel x86 cpus). Type C-r @@ -4096,71 +4082,6 @@ minimum supported Windows version is 8.1, and the computer hardware (CPU, memory, disk) should also match the minimum Windows 8.1 requirements. -*** Segfault during 'make' - -If Emacs segfaults when 'make' executes one of these commands: - - LC_ALL=C ./temacs -batch -l loadup bootstrap - LC_ALL=C ./temacs -batch -l loadup dump - -the problem may be due to inadequate workarounds for address space -layout randomization (ASLR), an operating system feature that -randomizes the virtual address space of a process. ASLR is commonly -enabled in Linux and NetBSD kernels, and is intended to deter exploits -of pointer-related bugs in applications. If ASLR is enabled, the -command: - - cat /proc/sys/kernel/randomize_va_space # GNU/Linux - sysctl security.pax.aslr.global # NetBSD - -outputs a nonzero value. - -These segfaults should not occur on most modern systems, because the -Emacs build procedure uses the command 'setfattr' or 'paxctl' to mark -the Emacs executable as requiring non-randomized address space, and -Emacs uses the 'personality' system call to disable address space -randomization when dumping. However, older kernels may not support -'setfattr', 'paxctl', or 'personality', and newer Linux kernels have a -secure computing mode (seccomp) that can be configured to disable the -'personality' call. - -It may be possible to work around the 'personality' problem in a newer -Linux kernel by configuring seccomp to allow the 'personality' call. -For example, if you are building Emacs under Docker, you can run the -Docker container with a security profile that allows 'personality' by -using Docker's --security-opt option with an appropriate profile; see -. - -To work around the ASLR problem in either an older or a newer kernel, -you can temporarily disable the feature while building Emacs. On -GNU/Linux you can do so using the following command (as root). - - echo 0 > /proc/sys/kernel/randomize_va_space - -You can re-enable the feature when you are done, by echoing the -original value back to the file. NetBSD uses a different command, -e.g., 'sysctl -w security.pax.aslr.global=0'. - -Alternatively, you can try using the 'setarch' command when building -temacs like this, where -R disables address space randomization: - - setarch $(uname -m) -R make - -ASLR is not the only problem that can break Emacs dumping. Another -issue is that in Red Hat Linux kernels, Exec-shield is enabled by -default, and this creates a different memory layout. Emacs should -handle this at build time, but if this fails the following -instructions may be useful. Exec-shield is enabled on your system if - - cat /proc/sys/kernel/exec-shield - -prints a nonzero value. You can temporarily disable it as follows: - - echo 0 > /proc/sys/kernel/exec-shield - -As with randomize_va_space, you can re-enable Exec-shield when you are -done, by echoing the original value back to the file. - *** openSUSE 10.3: Segfault in bcopy during dumping. This is due to a bug in the bcopy implementation in openSUSE 10.3. @@ -4308,17 +4229,6 @@ should do. pen@lysator.liu.se says (Feb 1998) that the Compose key does work if you link with the MIT X11 libraries instead of the Solaris X11 libraries. -** OpenBSD - -*** OpenBSD 4.0 macppc: Segfault during dumping. - -The build aborts with signal 11 when the command './temacs --batch ---load loadup bootstrap' tries to load files.el. A workaround seems -to be to reduce the level of compiler optimization used during the -build (from -O2 to -O1). It is possible this is an OpenBSD -GCC problem specific to the macppc architecture, possibly only -occurring with older versions of GCC (e.g. 3.3.5). - ** AIX *** AIX 4.3.x or 4.4: Compiling fails. -- 2.39.5