thakur@eddie.mit.edu (Manavendra K. Thakur) (06/28/90)
In article <9124@brazos.Rice.edu> you write: > >I am trying to build 18.55 with gcc-1.37 under SunOS 4.1 It compiles but >when temacs is run for the dump it seg. faults instead. It works fine if >you use cc. This sounds suspiciously like the problem I've been having. If so, there's a patch available. If you run temacs through a debugger (gdb, dbx) you'll see that it is dying in alloc.c with a Bus error. (Important note: there is another problem with emacs under 4.1, which causes emacs to core dump but is unrelated to gcc and alloc.c. This has to do with a bug in a static function called by the 4.1 tzsetwall routine, which clears the 9th byte past an 8 byte region it mallocs. There's a separate patch to GnuEmacs' malloc.c which will work around this SunOS4.1 bug [mail me if you want it], or you can simply add "#define SYSTEM_MALLOC" to the config.h file.) To test whether the alloc.c bug is the problem you're running up against, compile alloc.c with cc and everything else with gcc. If the resulting temacs completes its dump without bombing out with a Bus error (i.e., the sun cc compiled alloc.o does not crash), then you've hit the alloc.c problem. Fortunately, there's a patch, which is attached below. You simply have to apply the patch to alloc.c and recompile. For those who want to know more about the bug, here is the code in alloc.c that causes the gcc-compiled executable to give a Bus error: #define NSTATICS 200 char staticvec1[NSTATICS * sizeof (Lisp_Object *)] = {0}; int staticidx = 0; #define staticvec ((Lisp_Object **) staticvec1) The problem is that gcc isn't aligning the array staticvec1 to a word boundary and the sun compiler is. So the routine staticpro in alloc.c will die with a bus error when it tries to execute the following statement: staticvec[staticidx++] = varaddress; More specifically, the assembler instruction that stores the value of vararddress will attempt to store it into an bad memory location. Hence the bus error when temacs runs. However, since staticvec1 is an array of char, gcc is within its rights not to align it. Anyway, the fix is to simply rewrite the code so that staticvec1 is an array of int, and gcc will happily align it properly. By the way, I should point out that I certainly didn't figure all this out. This info is coming courtesy of Michael Meissner <meissner@osf.org> and Alan M. Carroll <carroll@cs.uiuc.edu>. They deserve the credit. Ok, here's the patch. Enjoy. Manavendra K. Thakur Internet: thakur@zerkalo.harvard.edu System Manager, High Energy Division BITNET: thakur@cfa.BITNET Harvard-Smithsonian Center for DECNET: CFA::thakur Astrophysics UUCP: ...!uunet!mit-eddie!thakur ====== CUT HERE ====== *** alloc.c.orig Tue Jan 23 11:42:27 1990 --- alloc.c Wed Jun 27 14:22:47 1990 *************** *** 665,673 **** #define NSTATICS 200 char staticvec1[NSTATICS * sizeof (Lisp_Object *)] = {0}; int staticidx = 0; - - #define staticvec ((Lisp_Object **) staticvec1) /* Put an entry in staticvec, pointing at the variable whose address is given */ --- 665,676 ---- #define NSTATICS 200 + #ifdef __GNUC__ + Lisp_Object *staticvec[NSTATICS] = {0}; + #else char staticvec1[NSTATICS * sizeof (Lisp_Object *)] = {0}; + #define staticvec ((Lisp_Object **) staticvec1) + #endif int staticidx = 0; /* Put an entry in staticvec, pointing at the variable whose address is given */