* (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).