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

[Ishikawa <ishikawa at yk dot rim dot or dot jp>]

Jim Wilson wrote:
> 
> Gerald, does this look reasonable for the 3.3 release notes?  This is to
> document problems building GNU Emacs with gcc-3.3.  I tested this
> against the xhtml validator.

Hi,

Thank you for taking the time to
pick up my post and trying to reflect it in gcc's release note.

It turns out that the early explanation given by Paul Eggert
was misleading and he himself clarified the problem as in the posting
below.

It looks that -fno-zero-initialized-in-bss has nothing to do
with the crash (it may cause a subtle performance drop
on a heavily used TSS machine which may not exist in large numbers
today), and the crash is more likely to be caused
by the subtle change in the ELF segment attribute
produced by the GCC 3.3 under Solaris 8 (and 9?) for  ultraSparc.

So instead of the suggested change, a simple
statement like "GCC 3.3 is known to break
compilation and installation of GNU Emacs 21.3 under
Solaris 8 for ultraSparc. Please get the latest patches for Emacs."
in the top summary section might be more helpful.

Sorry about causing so much trouble, but the problem is indeed
subtle and obviously the segments layout problem appears
on some people's machines, but not on someone. Amazing, but
it is real and Paul's unexec() patch  fixed the problem once
for all.

Thank you again.

Happy Hacking,

Ishikawa, Chiaki.

PS: Paul's clarification just in case the post didn't reach
relevant mailing lists.

Subject:        Re: (RFC) GCC minor document change: gcc.1
Date:           Tue, 15 Jul 2003 00:34:21 -0700 (PDT)
From:           Paul Eggert <eggert@twinsun.com>
To:           ishikawa@yk.rim.or.jp
CC:           gcc-patches@gcc.gnu.org, emacs-pretesters@gnu.org,
emacs-devel@gnu.org, ebotcazou@gcc.gnu.org

> 
> > 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.
> 
 

-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */