mb@ttidca.UUCP (01/29/87)
Has anyone succeeded in getting either the emacs version of unexec.c or any other version of unexec to work with SysV Release 2? What checks does the USG release 2 kernel make on header fields or other attributes of a COFF binary that were not made in earlier releases? And why does the exec apparently succeed before it has finished making all such checks? This seems to be the case; it tries to load the binary produced by unexec, but the entry point does not get called. In trying to build emacs on a National Semi ICM3216, I have run against several problems. The first was that malloc itself would crap out. This was because for some bizarre reason, ulimit(3,0) was returning a number in the 300,000 range rather than the 8 meg it should in Nationals release of unix. This was fixed by "#define ULIMIT_BUG 8192000" in the appropriate .h file, and conditionalizing the code that calls ulimit. The second was that unexec would crap out with a SEGV when it got to the point of trying to copy the memory between text and data. snarfing the code from the v18 unexec which understands such events fixed this problem. After the above fixes were done, temacs would successfully create a new a.out file, but an unusable one. The reason I have been working with v17, rather than v18, is that it is documented that something broke for release 2 systems between version 17 and version 18 of unexec. If anyone has had success with unexec, or has some suggestions on things to check, I'd like to hear from you. mb@ttidca.tti.com (if you are not on the internet) mb@ttidca.uucp (if you are on the internet - we're waiting for a forwarder)
mb@ttidca.UUCP (01/30/87)
In article <358@ttidca.UUCP> mb@ttidca.UUCP (Michael Bloom) writes: >Has anyone succeeded in getting either the emacs version of unexec.c >or any other version of unexec to work with SysV Release 2? oops (how do you draw a red faced smiley face?). This turned out to be a case of RTFM. After spending some time poring over various .h files and the COFF and link editor manuals, I found that the end of the text region and start of the data region had to be on opposite sides of a 64kb (!!!) boundary. This is due to the way regions (text/data/bss) are mapped. While paging granularity itself is much smaller, 64kb is the granularity used for protection (read/write/shared, etc). I don't know yet whether this is peculiar to the ICM-3216 architecture, or is generic for SysVr2. Would someone care to comment on this? Using a value of 0xffff0000 for the ADDR_CORRECT macro, I was able to produce a runnable xemacs. It has some rather profound display problems however (for a control, I built it with termcap instead of terminfo, and used a termcap entry that I know to be correct fro emacs on vaxes and pyramids), so I'm still working on it. Once I'm satisfied, I'll post an appropriate m- file to comp.emacs. I'd like to hear from anyone who knows if this 64k region size is typical of other system Vr2 ports. - Michael Bloom
fnf@mcdsun.UUCP (02/01/87)
In article <368@ttidca.UUCP> mb@ttidca.UUCP (Michael Bloom) writes: >While paging granularity itself is much smaller, 64kb is the >granularity used for protection (read/write/shared, etc). I don't >know yet whether this is peculiar to the ICM-3216 architecture, or is >generic for SysVr2. Would someone care to comment on this? > >I'd like to hear from anyone who knows if this 64k region size is >typical of other system Vr2 ports. As the guilty party who did the first known port of GNU emacs to System V, and the original unexec stuff for COFF, guess I'll comment on this. One of the most frustrating artifacts of Motorola not having a fast flexible MMU available for the 68000 family, until just recently with the MC68851, is that practically everyone and their brother producing 68K based Unix systems did their own MMU hardware. Just ask the folks at Unisoft (my previous employer) who have done literally hundreds of ports of Unix to 68K based hardware, about some of the bizarre MMU schemes they have had to deal with. Where text starts, where data starts, and how big (if any) a hole there is between the two, are dictated by MMU considerations. Many configurations require text to start at some non-zero address (0x80000 for example). Some require as much as a 4Mb hole between the end of text and the start of data. In short, there are no guarantees about where text and data are located and whether or not they are even relatively close to each other in the address space. -Fred -- =========================================================================== Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA {seismo!noao!mcdsun,hplabs!well}!fnf (602) 438-5976 ===========================================================================
jhh@ihlpl.UUCP (02/07/87)
> I'd like to hear from anyone who knows if this 64k region size is > typical of other system Vr2 ports. > > - Michael Bloom Well, the Amdahl that I am posting this from will be shortly converting to region boundaries of 1 megabyte, using 370/XA. Of course, the machine actually has 64 megabytes of memory. (Well, the actual machine has 256 megabytes, but it is split into 2 virtual unix(R) systems, and the one I am using only has access to 64 megabytes of real memory.) John Haller AT&T Bell Laboratories