From: Paul Eggert <eggert@twinsun.com>
Cc: gcc-patches@gcc.gnu.org, emacs-pretesters@gnu.org,
emacs-devel@gnu.org, ebotcazou@gcc.gnu.org
Subject: Re: (RFC) GCC minor document change: gcc.1
Date: Tue, 15 Jul 2003 00:34:21 -0700 (PDT) [thread overview]
Message-ID: <200307150734.h6F7YLi13759@green.twinsun.com> (raw)
In-Reply-To: <3F1344D4.9BCA454@yk.rim.or.jp> (ishikawa@yk.rim.or.jp)
> Date: Tue, 15 Jul 2003 09:03:32 +0900
> From: Ishikawa <ishikawa@yk.rim.or.jp>
> ! 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.
next prev parent reply other threads:[~2003-07-15 7:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-14 23:52 (RFC) GCC minor document change: gcc.1 ishikawa
2003-07-14 23:55 ` Andrew Pinski
2003-07-15 0:03 ` Ishikawa
2003-07-15 4:41 ` Jim Wilson
2003-07-15 5:46 ` Ishikawa
2003-07-15 7:34 ` Paul Eggert [this message]
2003-07-15 16:23 ` Ishikawa
2003-07-15 23:46 ` Ishikawa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200307150734.h6F7YLi13759@green.twinsun.com \
--to=eggert@twinsun.com \
--cc=ebotcazou@gcc.gnu.org \
--cc=emacs-devel@gnu.org \
--cc=emacs-pretesters@gnu.org \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).