Re: (RFC) GCC minor document change: gcc.1

[Paul Eggert]

> Date: Tue, 15 Jul 2003 09:03:32 +0900
> From: Ishikawa <address@hidden>

> ! This option turns off this behavior because some programs,
> ! most notably GNU Emacs 21.3 and prior versions,
> ! explicitly
>   rely on variables going to the data section.

This statement is misleading, for two reasons.  First, this is merely
an efficiency issue for Emacs; it is not a correct-behavior issue.
Second, I don't know of any real hosts where the efficiency issue
actually arises.

I am mainly responsible for this misunderstanding, since I originally
sent incorrect messages to emacs-devel and emacs-pretesters implying
that -fno-zero-initialized-in-bss caused the core dump on Solaris 8.
(I was wrong: the real bug was in Emacs's src/unexelf.c.)
So I'd like to make amends by clarifying the two issues as best I can.

First, Emacs relies on zero-initialized data being put into the data
(not bss) as an optimization on hosts that:

 (1) lack virtual memory, or have VM but lack copy-on-write for data segments;
 (2) commonly have multiple instances of Emacs running;
 (3) have an unexec that stores the array 'pure' into read-only shared text;
 (4) are so slow that people notice speedup if 'pure' is shared; and
 (5) have a compiler that optimizes allocations of zeros like GCC 3.3 sparc.

Sharing the 'pure' array is purely an efficiency issue: it is not
something that can lead to a core dump if the array is actually put
into BSS (and is thus not shared in an unexec'ed emacs).

Second, it's not clear that the efficiency issue actually arises on
any real platforms.  Hosts satisfying (1)-(4) were fairly common 15
years ago, but are rare Emacs platforms nowadays.  Furthermore, I
don't know of any hosts that satisfy both (3) and (5).  Solaris 8 with
GCC 3.3 satisfies (5) but not (3).  OpenBSD 3.2 with GCC 3.3 satisfies
(3) but not (5).  Perhaps some host satisfies both (3) and (5) -- as
well as the other constraints -- but I don't know of it.


Just in case, I have installed the following patch to the Emacs trunk:
<http://mail.gnu.org/archive/html/emacs-devel/2003-07/msg00257.html>
It ensures that Emacs's static arrays are initialized to nonzero.
This inhibits the -fno-zero-initialized-in-bss optimization, for
arrays where the efficiency issue might arise.

I doubt whether hosts satisfying (1) through (5) are worth worrying
about much these days.  But I installed the change to help keep the
Emacs code consistent with Emacs's current memory-allocation
philosophy, even on hosts that optimize allocations of zeros.