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)

diff --git a/doc/lispref/internals.texi b/doc/lispref/internals.texi
index 63c1761d72b58b4825217d5f10f97053519f1fca..be987e1f977e51f9a5fea396a0a821037ac49722 100644 (file)
--- 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 e28b150ad73bc070cf8698c57745abef431e20b0..6f1bb000a6b8be77f0fb2b71728850f0255afc9c 100644 (file)
--- 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 c9a208518d2dd229cc5d51056bca0cd61839166e..ee72a04f493c327aec92f24043bc2df851851226 100644 (file)
--- 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
-<https://docs.docker.com/engine/security/seccomp/>.
-
-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.