[jerry@cs.ucsb.edu (Jeremiah W. James)] [20.4] Irix 5.3 build troubles solved ... sort of
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>
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 -------