(RFC) GCC minor document change: gcc.1

(RFC) GCC minor document change: gcc.1

[ishikawa]

I would like to propose a minor document change for gcc/doc/gcc.1

This is prompted by a change of GCC 3.3 (from 3.2.3)
that breaks GNU Emacs
installation, but the documentation is not clear enough IMHO.

Please see bugzilla 11386 entry for the background:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386

The file is gcc/doc/gcc.1
If there are other popular programs that are affected,
I think their names should be explicitly mentioned.
(By doing so, we can save many debugging hours.)

I hope that similar clear warning is
incorporated into GNU Emacs's etc/MACHINES
document although future versions of GNU emacs
is probably free from the problem
thanks to Paul's patches. 
However, there may be people who needed to
compile and install 21.3 and older versions
due to some reasons.

*** gcc.1.saved	2003-07-15 08:35:10.000000000 +0900
--- gcc.1	2003-07-15 08:36:10.000000000 +0900
***************
*** 3284,3290 ****
  are initialized to zero into \s-1BSS\s0.  This can save space in the resulting
  code.
  .Sp
! This option turns off this behavior because some programs explicitly
  rely on variables going to the data section.  E.g., so that the
  resulting executable can find the beginning of that section and/or make
  assumptions based on that.
--- 3284,3292 ----
  are initialized to zero into \s-1BSS\s0.  This can save space in the resulting
  code.
  .Sp
! This option turns off this behavior because some programs, most
! notably
! GNU Emacs 21.3 and its prior versions,  explicitly
  rely on variables going to the data section.  E.g., so that the
  resulting executable can find the beginning of that section and/or make
  assumptions based on that.




Happy Hacking,

Ishikawa, Chiaki

PS: Sorry for some "message unavailable" missing
links in the related thread in emacs-devel.
I think this is due to my bounced messages.

I found out that my e-mail set up (for GNU emacs mail buffer) was
screwed up and that is why my previous attempt to post to
emacs-*@gnu.org bounced. GNU mailing list software is strict in that
From: address contains reachable address, I think.

I only realized the problem when I see my e-mail address was quoted as
ishikawa@bogus.example.com in a message posted by Paul (I cc:ed to
Paul.)

I am hoping this time, it works.

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

[Andrew Pinski]

On Monday, Jul 14, 2003, at 19:52 US/Eastern, ishikawa@yk.rim.or.jp 
wrote:
> I would like to propose a minor document change for gcc/doc/gcc.1

You do not want to patch gcc.1 but one of the files, doc/*.texi as 
gcc.1 is generated from them.

Thanks,
Andrew Pinski

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

[Ishikawa]

Andrew Pinski wrote:
> 
> On Monday, Jul 14, 2003, at 19:52 US/Eastern, ishikawa@yk.rim.or.jp
> wrote:
> > I would like to propose a minor document change for gcc/doc/gcc.1
> 
> You do not want to patch gcc.1 but one of the files, doc/*.texi as
> gcc.1 is generated from them.
> 
> Thanks,
> Andrew Pinski

Quite right.

The file that should be patched is invoke.texi.

*** invoke.texi.saved	2003-07-15 09:01:20.000000000 +0900
--- invoke.texi	2003-07-15 09:01:44.000000000 +0900
***************
*** 3624,3630 ****
  are initialized to zero into BSS@.  This can save space in the resulting
  code.
  
! This option turns off this behavior because some programs explicitly
  rely on variables going to the data section.  E.g., so that the
  resulting executable can find the beginning of that section and/or make
  assumptions based on that.
--- 3624,3632 ----
  are initialized to zero into BSS@.  This can save space in the resulting
  code.
  
! 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.  E.g., so that the
  resulting executable can find the beginning of that section and/or make
  assumptions based on that.


I hope someone can incorporate this minor change into
CVS tree.


-- 
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 */

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

[Jim Wilson]

Ishikawa wrote:
> The file that should be patched is invoke.texi.

I don't think this helps much.  Someone reading the documentation for
the -fno-zero-initialized-in-bss option to learn what it does isn't
helped by the fact that it affects GNU Emacs.  Someone reading the
documentation to figure out why GNU Emacs doesn't work isn't going to
know that they are supposed to look at the documentation for this option.

I suggest putting the info someplace else, such as in the 3.3 release notes.
	http://gcc.gnu.org/gcc-3.3/changes.html
Or maybe on the known bugs page.
	http://gcc.gnu.org/bugs.html#known
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

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

[Ishikawa]

Jim Wilson wrote:
> 
> Ishikawa wrote:
> > The file that should be patched is invoke.texi.
> 
> I don't think this helps much.  Someone reading the documentation for
> the -fno-zero-initialized-in-bss option to learn what it does isn't
> helped by the fact that it affects GNU Emacs.  Someone reading the
> documentation to figure out why GNU Emacs doesn't work isn't going to
> know that they are supposed to look at the documentation for this option.

I agree that this is not among the first files, someone
with the problem is going to read.
 
> I suggest putting the info someplace else, such as in the 3.3 release notes.
>         http://gcc.gnu.org/gcc-3.3/changes.html
> Or maybe on the known bugs page.
>         http://gcc.gnu.org/bugs.html#known

I think the former may be good enough.

Now I am wondering if the message is reaching people who has 
the authority to modify the changes.html.


-- 
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 */

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

[Paul Eggert]

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

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

[Ishikawa]

Paul Eggert wrote:
> 
> > 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.
> 
	[ ... ]

Dear Paul,

Thank you for your clarification.

So it means that, basically, the
new code layout somehow produced by GCC 3.3
triggered a bug in unexelf.c, which was
fixed in your previous posting.

OK, then we don't have to put the change in 
the gcc documentation about -fno-zero-initialized-in-bss causing
problems for GNU Emacs (although I certainly can believe
some embedded folks will be bitten for once when I think about it, but
I digress.).

Below is not directed to Paul per se, but to the CC:s mailing lists.

Now I am wondering what we should do about the problem of
GCC 3.3 + and unpatched GNU Emacs 21.3 combination under Solaris 8.
Since GCC 3.2.3 + GNU Emacs 21.3 works and
GCC 3.3 + GNU Emacs 21.3 doesn't, I still would like
to  see  a mention of the problem in some visible places
unless GNU Emacs 21.4 that fixes this problem is released very soon.
But where should we put the warning?
My feeling as the end user is on gcc's changes.html, but
there may be a better place. It is a pity that GCC 3.3's change page
doen't mention this zero-initialized-in-bss feature of GCC 3.3 in any
case.

At the end of GCC 3.3's  changes.html, it says:
>Please send comments on these web pages and GCC to our public mailing list at gcc@gnu.org or gcc@gcc.gnu.org, send >other questions to gnu@gnu.org.

Is sending this to gcc-patches enough or should I send to gcc mailing
list as well?

Happy Hacking,

Ishikawa, Chiaki
 
PS: For reasons I don't know (maybe my netscape's MIME header specifying
ISO-2022-JP is not liked by the mailing list software),
my post to emacs-pretester seems to bounce constantly. Again sorry
if there is a hole in the threaded listing of the mailing archive.





 
-- 
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 */

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

[Ishikawa]

Hi,

Paul Eggert wrote:
> 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>

This is somewhat off-topic, but
my incorrect setup of e-mail address
when I used Emacs mail buffer to
post articles on local Debian GNU/Linux 
somehow propagated to the above post:
I just noted Paul's e-mail address was mangled into
eggert@bogus.example.com from the usual one in the
archived copy at the above URL.
I hope this won't cause something inconvenient.
(It certainly cause something bad to the Spammers who
crawl these archives for e-mail addresses!)

This post should have a correct e-mail address.

-- 
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 */