* (RFC) GCC minor document change: gcc.1
@ 2003-07-14 23:52 ishikawa
2003-07-14 23:55 ` Andrew Pinski
0 siblings, 1 reply; 8+ messages in thread
From: ishikawa @ 2003-07-14 23:52 UTC (permalink / raw
Cc: ebotcazou
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: (RFC) GCC minor document change: gcc.1
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
0 siblings, 1 reply; 8+ messages in thread
From: Andrew Pinski @ 2003-07-14 23:55 UTC (permalink / raw
Cc: Andrew Pinski, gcc-patches, emacs-pretesters, emacs-devel, eggert,
ebotcazou
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: (RFC) GCC minor document change: gcc.1
2003-07-14 23:55 ` Andrew Pinski
@ 2003-07-15 0:03 ` Ishikawa
2003-07-15 4:41 ` Jim Wilson
2003-07-15 7:34 ` Paul Eggert
0 siblings, 2 replies; 8+ messages in thread
From: Ishikawa @ 2003-07-15 0:03 UTC (permalink / raw
Cc: emacs-pretesters, emacs-devel, eggert, ebotcazou
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 */
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: (RFC) GCC minor document change: gcc.1
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
1 sibling, 1 reply; 8+ messages in thread
From: Jim Wilson @ 2003-07-15 4:41 UTC (permalink / raw
Cc: emacs-pretesters, emacs-devel, eggert, ebotcazou, gcc-patches
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: (RFC) GCC minor document change: gcc.1
2003-07-15 4:41 ` Jim Wilson
@ 2003-07-15 5:46 ` Ishikawa
0 siblings, 0 replies; 8+ messages in thread
From: Ishikawa @ 2003-07-15 5:46 UTC (permalink / raw
Cc: emacs-pretesters, emacs-devel, eggert, ebotcazou, gcc-patches
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 */
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: (RFC) GCC minor document change: gcc.1
2003-07-15 0:03 ` Ishikawa
2003-07-15 4:41 ` Jim Wilson
@ 2003-07-15 7:34 ` Paul Eggert
2003-07-15 16:23 ` Ishikawa
2003-07-15 23:46 ` Ishikawa
1 sibling, 2 replies; 8+ messages in thread
From: Paul Eggert @ 2003-07-15 7:34 UTC (permalink / raw
Cc: gcc-patches, emacs-pretesters, emacs-devel, ebotcazou
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: (RFC) GCC minor document change: gcc.1
2003-07-15 7:34 ` Paul Eggert
@ 2003-07-15 16:23 ` Ishikawa
2003-07-15 23:46 ` Ishikawa
1 sibling, 0 replies; 8+ messages in thread
From: Ishikawa @ 2003-07-15 16:23 UTC (permalink / raw
Cc: gcc-patches, emacs-pretesters, emacs-devel, ebotcazou
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 */
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: (RFC) GCC minor document change: gcc.1
2003-07-15 7:34 ` Paul Eggert
2003-07-15 16:23 ` Ishikawa
@ 2003-07-15 23:46 ` Ishikawa
1 sibling, 0 replies; 8+ messages in thread
From: Ishikawa @ 2003-07-15 23:46 UTC (permalink / raw
Cc: gcc-patches, emacs-pretesters, emacs-devel, ebotcazou
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 */
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-07-15 23:46 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2003-07-15 16:23 ` Ishikawa
2003-07-15 23:46 ` Ishikawa
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).