Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-spam!sri-unix!hplabs!decwrl!pyramid!prls!philabs!ttidca!mb
From: mb@ttidca.UUCP
Newsgroups: comp.unix.wizards,comp.emacs
Subject: Re: building a.outs in COFF format
Message-ID: <368@ttidca.UUCP>
Date: Fri, 30-Jan-87 06:58:10 EST
Article-I.D.: ttidca.368
Posted: Fri Jan 30 06:58:10 1987
Date-Received: Sat, 31-Jan-87 19:44:18 EST
References: <358@ttidca.UUCP>
Reply-To: mb@ttidca.UUCP (Michael Bloom)
Organization: CitiCorp TTI, Santa Monica, Ca.
Lines: 28
Summary: red faced, have answer.
Xref: watmath comp.unix.wizards:769 comp.emacs:375

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