[5251] in testers
Re: emacs -nw broken on IRIX
daemon@ATHENA.MIT.EDU (Robert A Basch)
Fri Jun 28 18:04:33 2002
Message-Id: <200206282204.SAA27945@abulia.mit.edu>
To: Robert A Basch <rbasch@MIT.EDU>
cc: testers@MIT.EDU
In-Reply-To: Your message of "Tue, 18 Jun 2002 13:32:14 EDT."
<200206181732.NAA23748@abulia.mit.edu>
Date: Fri, 28 Jun 2002 18:04:30 -0400
From: Robert A Basch <rbasch@MIT.EDU>
I've tracked down the problem enough to be able to provide a workaround
for 9.1, though I do not yet fully understand it. Here are some notes
on what I have found:
- Nothing gets displayed because no data is actually written to file
descriptor 1; the stdout stream buffering is apparently broken.
- Building with the native compiler works. (Which is why I didn't notice
the problem before; we briefly switched to the native compiler earlier,
in a misguided attempt to work around the mmap bug).
- Building with gcc 2.95 works.
- Building with gcc 3.0, the unexec step apparently breaks stdout; things
work fine if you #define CANNOT_DUMP in src/m/iris4d.h.
- I tried building emacs 21.2 (which has significant changes to unexelf.c),
and with the unexelf.c from the emacs mainline; in both cases, the unexec
produced broken executables that die on startup.
- In emacs 20, the unexec used sgi-specific code in unexsgi.c; that was
apparently merged into unexelf.c; things work if you build emacs 21
with the unexsgi.c from emacs 20.
- By using elfdump to examine differences between the temacs and emacs
executables using both gcc and the native compiler, and the changes
going from the emacs 20 unexsgi to unexelf, I narrowed the problem
to handling of the global offset table (.got section). Apparently,
references to __iob (stdio FILE array) are messed up somehow
following the unexec of an executable built using gcc. Copying
the .got section from the current process during unexec, instead
of from the temacs executable, avoids this lossage; the following
patch to unexelf.c makes this change successfully:
Index: unexelf.c
===================================================================
RCS file: /afs/dev.mit.edu/source/repository/third/emacs/src/unexelf.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 unexelf.c
--- unexelf.c 2002/02/08 04:31:41 1.1.1.4
+++ unexelf.c 2002/06/28 18:05:44
@@ -990,6 +990,10 @@
if (!strcmp (old_section_names + NEW_SECTION_H (n).sh_name, ".data")
|| !strcmp ((old_section_names + NEW_SECTION_H (n).sh_name),
".sdata")
+#ifdef __sgi
+ || !strcmp (old_section_names + NEW_SECTION_H (n).sh_name,
+ ".got")
+#endif
|| !strcmp ((old_section_names + NEW_SECTION_H (n).sh_name),
".lit4")
|| !strcmp ((old_section_names + NEW_SECTION_H (n).sh_name),
This change works for both gcc and the native compilers on IRIX; the
#ifdef is needed, though, as copying the GOT from the process breaks
the linux unexec.
I hope to follow up on this when time permits, but at this point I
think our best bet is to revert back to using the native compiler.
The above patch works, but will inevitably cause a merge conflict down
the road (by which point we will no longer care about building on SGI,
with any luck); I also fear there could be other subtle problems when
using gcc. (We could just disable unexec on SGI, but I feel like I
have wasted enough time in my life waiting for an undumped emacs to
start up).
I will submit a patch to revert the compiler.
Bob
