Could some Irix person follow up on this? Martin ------- Start of forwarded message ------- Date: Sat Apr 25 01:14:09 1998 From: jerry(a)cs.ucsb.edu (Jeremiah W. James) Subject: [20.4] Irix 5.3 build troubles solved ... sort of Topics: [20.4] Irix 5.3 build troubles solved ... sort of ---------------------------------------------------------------------- Date: 22 Apr 1998 15:33:08 -0700 From: jerry(a)cs.ucsb.edu (Jeremiah W. James) Subject: [20.4] Irix 5.3 build troubles solved ... sort of Message-ID: <tprlnsxcwrf.fsf(a)cs.ucsb.edu&gt; Content-Type: text/plain; charset=US-ASCII I mentioned a problem with the dumped xemacs (version 20.4) seg faulting on Irix 5.3 a while ago, and even talked with a few of the maintainers via email about it for a time. Well, I finally have an explanation and a partial solution to the problem. Here's what happens. First, temacs is built and then runs. Its job is to initialize a bunch of stuff, and especially to preload some lisp files. Then it dumps an image of itself into the xemacs executable. When you run xemacs, it starts up with a bunch of stuff already set to go, greatly reducing startup time. The dumping process has to avoid a pitfall relating to bss sections. Uninitialized variables go into the .bss section, which is zero-filled by the loader when the program is run. Since xemacs was dumped with runtime values that need to be restored, you don't want those variables zero-filled when xemacs starts up. The solution is to create a new data section, copy the contents of the .bss section to the new data section, and then use that same data section to hold the preloaded Lisp files. A zero-length .bss section is written out to the final executable, to avoid trouble with loaders that expect to find one. All this is fine. The trouble I encountered arises from the .sbss (for "small bss") section. The idea is to put small uninitialized data items into this section, set aside one register (the global pointer) to point into it, and use 16-bit offsets from that register to access those data items, rather than full 32-bit pointers. This results in smaller (and hopefully faster) code. The unexelfsgi.c file contains a supposed solution to the .sbss problem. It sets a flag on that section which is supposed to tell the loader that it is a data section, rather than a .bss section. The loader is supposed to see that flag and skip the zero filling process. It doesn't work. The seg faults I was seeing resulted from the .sbss section being zero-filled. Unfortunately, _heapbase lived in .sbss, so the first heap access tried to dereference a null pointer. Instant flaming death followed. It turns out that the loader completely ignores the flags on the .sbss section. It looks for sections *named* .bss and .sbss, and zero fills them, regardless of flags. This happens on Irix 5.3, with both an unpatched machine and one with the latest recommended patchset from SGI. I would like to know what version of Irix was used by Olivier Galibert (who wrote the .sbss support). It seems it wasn't 5.3. The solution to the problem is to pull a trick similar to the one for .bss. That is, create a new (small) data section, and copy .sbss into it. I think in this case it should be safe to discard the .sbss section completely, rather than creating a zero-length .sbss. Unfortunately, this task is somewhat beyond the current state of my knowledge. Is there anybody out there who could do this? Temporary workaround: compile with -G 0. That tells the compiler/linker to not create an .sbss section in the first place. This is the solution I employed to finally get a working XEmacs 20.4 on Irix 5.3. Note that - G defaults to zero on some systems, so some people will never see the problem at all. Also, -G 0 is not needed (or even wanted) in lib-src since those executables aren't loaded up and dumped. Incidentally, if someone does work on unexelfsgi.c, would you wipe out a few warnings by removing the declaration of new_data2_index from unexec (it isn't set or used anywhere), and removing the zero argument from 5 or 6 calls to fatal? Thanks! - - Jerry James Email: jerry(a)cs.ucsb.edu WWW: http://www.cs.ucsb.edu/~jerry/ ------------------------------ End of forwardayAOYW Digest *************************** ------- End of forwarded message -------