tim@banyan.UUCP (Tim Henrion) (12/16/87)
I am trying to port GNU Emacs 18.49 to a Compaq 386 running Unix 5.3. I got everything building fine until the point where 'temacs' started loading up the standard lisp code and dumping itself to 'xemacs'. Everything worked O.K. except for the fact that the resulting 'xemacs' image was 4.5 MEGABYTES LONG! Needless to say, our 5.3 port has trouble executing images that big. This seems really odd to me since the size of the EMACS image on my 11/785 running 4.3 is only about 533K. I know that they are different machines but 4.5 Mb seems ridiculous even for GNU. Is there something that I have overlooked here in the build process? Help from any GNU porting wizards would be greatly appreciated. ---------------------------------------------------------------------------- Tim Henrion Communications Software Engineer UUCP: ...!necntc!banyan!tim Banyan Systems, Inc. VOICE: (617) 898-1116 115 Flanders Road Westboro, MA 01581 "Are you sure you're circuits are registering properly?, you're ears are green!" -- Mr. Spock
karl@mumble.cis.ohio-state.edu (Karl Kleinpaste) (12/18/87)
tim@banyan.UUCP writes:
I am trying to port GNU Emacs 18.49 to a Compaq 386 running Unix 5.3.
I got everything building fine until the point where 'temacs'
started loading up the standard lisp code and dumping itself to
'xemacs'. Everything worked O.K. except for the fact that the
resulting 'xemacs' image was 4.5 MEGABYTES LONG!
You're probably up against COFF requirements for your system, for the
space between text and data segments. Among other things, check what
you're doing with NO_REMAP, which prevents text/data boundary
remapping for systems where the segmentation habits are not good.
(3Bs have this problem.) Look up the COFF constants used in <a.out.h>
and all the other header files it includes for info on what's going
on.
-=-
Karldougm@ico.UUCP (Doug McCallum) (12/31/87)
In article <228@banyan.UUCP> tim@banyan.UUCP (Tim Henrion) writes: >I am trying to port GNU Emacs 18.49 to a Compaq 386 running Unix 5.3. ... >resulting 'xemacs' image was 4.5 MEGABYTES LONG! Needless to say, You have to define NO_REMAP. 5.3 is using regions aligned on 4Mb boundaries. If you try to remap, you will get the result you are seeing. There are a couple of other places you are going to get hit with. If you aren't converting to using the the 5.3 opendir/closedir, etc. you won't have the problem, but then you can't access other file systems that might be defined in the file system switch. If you convert, there is a bad interaction between the GNU malloc routines and the closedir call. The symptom is running out of file descriptors. The fix is to make a version of closedir that closes the file descriptor before calling free. Doug McCallum Interactive Systems dougm@ico.isc.com
jum@cosmo.UUCP (Uwe Mager) (01/03/88)
In article <2381@ico.UUCP> dougm@ico.UUCP (Doug McCallum) writes: >You have to define NO_REMAP. 5.3 is using regions aligned on 4Mb >boundaries. If you try to remap, you will get the result you are >seeing. I encountered just the same problem on an sysV68 3.0 machine, I solved it by writing a linker control file to align to a 1Kbyte boundary only, and everything works fine. Is there any problems with this approach ? -- Jens-Uwe Mager jum@focus.UUCP || jum@cosmo.UUCP
weinberg@necis.UUCP (Glenn Weinberg) (01/07/88)
In article <394@cosmo.UUCP> jum@cosmo.UUCP (Jens-Uwe Mager) writes: >In article <2381@ico.UUCP> dougm@ico.UUCP (Doug McCallum) writes: >>You have to define NO_REMAP. 5.3 is using regions aligned on 4Mb >>boundaries. If you try to remap, you will get the result you are >>seeing. > >I encountered just the same problem on an sysV68 3.0 machine, I solved it >by writing a linker control file to align to a 1Kbyte boundary only, and >everything works fine. Is there any problems with this approach ? There may or may not be, depending on how generous the loader (i.e., the code in the exec system call) is in your kernel. Generally, these alignment restrictions are there to make the kernel's page table allocation mechanisms easier and/or to deal with hardware (MMU) protection alignment restrictions. If you use a non-standard alignment, the kernel has a few choices: 1) It can blow you out of the water intentionally; 2) if allowed by the hardware, it can support the non-standard alignment less efficiently than the standard alignment, which could affect system performance; 3) if allowed by the hardware, it can support the non-standard alignment with loss of protection, i.e., it can make (part or all) of your text region writeable; or 4) it can assume correct alignment and blow you, and possibly everyone else on the system, out of the water accidentally. Apparently, your system does either (2) or (3). As long as you can get away with it, there's probably little or no harm in what you're doing, but it's certainly not guaranteed to work on all systems, or even on yours in the next release. -- Glenn Weinberg (weinberg@necis.nec.com) NEC Information Systems, 289 Great Road, Acton, MA 01720 (617) 263-3833