🚀 go-pugleaf

Here's a recapitulation of what's necessary for pmaxen/3maxen (DS3100/5000's,
compiling with MIPS cc under Ultrix 4.x).

(1) Besides the official "epoch-3.2-patch-1", apply the following patches.
    Note the the first is ABSOLUTELY necessary, otherwise you get data address
    faults all the time. [The last is for selections, simply makes life a
    breeze with xterm]:

-------------------------------------------------------------------------------
*** {original}/epoch-3.2/src/xresource.c	Tue Oct 16 19:45:27 1990
--- epoch-3.2/src/xresource.c	Thu Feb 21 17:13:59 1991
***************
*** 96,102 ****
      register Lisp_Object val;
      register struct Lisp_Xresource *xr;
  
!     if (xr_free_list)
  	{
  	xr = xr_free_list;
  	xr_free_list = XXRESOURCE(xr_free_list->next);
--- 96,102 ----
      register Lisp_Object val;
      register struct Lisp_Xresource *xr;
  
!     if (XUINT(xr_free_list))
  	{
  	xr = xr_free_list;
  	xr_free_list = XXRESOURCE(xr_free_list->next);
*** {original}/epoch-3.2/src/buffer.c	Thu Oct 18 17:21:22 1990
--- epoch-3.2/src/buffer.c	Tue Feb 19 10:24:56 1991
***************
*** 851,857 ****
    if (c == p)
      return;
  
!   if (w)
      swb = NULL (selected_window) ? 0 : XBUFFER (w->buffer);
  
    if (p && NULL (p->name))
--- 851,857 ----
    if (c == p)
      return;
  
!   if (selected_window)
      swb = NULL (selected_window) ? 0 : XBUFFER (w->buffer);
  
    if (p && NULL (p->name))
*** {original}/epoch-3.2/src/screen.c	Tue Oct 16 19:45:10 1990
--- epoch-3.2/src/screen.c	Wed Feb 27 22:20:19 1991
***************
*** 429,435 ****
  	XQueryColor(xs->display,cmap,&xcf);
  	xcfflag = 0;
  	}
!     if (xd.xfcursor && XParseColor(xs->display,cmap,xd.xbcursor,&xcb))
  	xcbflag = 1;
      else
  	{
--- 429,435 ----
  	XQueryColor(xs->display,cmap,&xcf);
  	xcfflag = 0;
  	}
!     if (xd.xbcursor && XParseColor(xs->display,cmap,xd.xbcursor,&xcb))
  	xcbflag = 1;
      else
  	{
*** {original}/epoch-3.2/src/x11fns.c	Tue Oct 16 19:45:23 1990
--- epoch-3.2/src/x11fns.c	Fri Feb 22 19:24:44 1991
***************
*** 93,98 ****
--- 93,99 ----
    check_xterm ();
  
    BLOCK_INPUT ();
+   XSetSelectionOwner(XD_display, XA_PRIMARY, None, CurrentTime);
    XStoreBytes (XD_display, XSTRING (string)->data,
  	       XSTRING (string)->size);
    UNBLOCK_INPUT ();
-------------------------------------------------------------------------------

(2) Here's what m-pmax.h should look like:

-------------------------------------------------------------------------------
#include "m-mips.h"
#undef LIBS_MACHINE
#undef BIG_ENDIAN

#ifdef IRIS
#undef IRIS /* Defined in m-mips.h? Don't need it. */
#endif

#ifdef DATA_START
#undef DATA_START /* Prevent cpp warnings about multiple defs. */
#endif

#ifdef DATA_SEG_BITS
#undef DATA_SEG_BITS /* Prevent cpp warnings about multiple defs. */
#endif

#ifdef LD_SWITCH_MACHINE
#undef LD_SWITCH_MACHINE
#define LD_SWITCH_MACHINE -D 10000000 /* conform to DATA_START */
#endif

#define SYSTEM_MALLOC
#define LD_SWITCH_SYSTEM

#define DATA_START 0x10000000
#define DATA_SEG_BITS 0x10000000
-------------------------------------------------------------------------------

NOTE, just FYI...

The LD_SWITCH_MACHINE redefine is essential, otherwise an incorrect value is
inherited from "m-mips.h", in which case one runs into the following. There's a
problem with the (*warnfunction) call in malloc.c:morecore() when memory's
getting tight. The warnfunction points to alloc.c:malloc_warning(). Due to the
above-described bad machine parameters, the first version I made thought there
was a memory crunch. Therefore main calls down the following tree:

main				(emacs.c)
init_alloc_once			(alloc.c)
init_strings			(alloc.c)
malloc				(malloc.c)
morecore			(malloc.c)
malloc_warning (*warnfunction)	(alloc.c)
build_string			(alloc.c)
make_string			(alloc.c)
make_uninit_string		(alloc.c)

init_strings contains the line:

  current_string_block =
	 (struct string_block *) malloc (sizeof (struct string_block));

malloc calls morecore, which calls malloc_warning through (*warnfunction)
because memory is (apparently) tight. This eventually gets us to
make_uninit_string, which contains the line:

  if (fullsize <= STRING_BLOCK_SIZE - current_string_block->pos)

which segmentation faults on current_string_block, since the higher call to
malloc has not yet returned to assign it in the first place.

-------------------------------------------------------------------------------
Chris Weikart (weikart@prl.dec.com)		  DEC Paris Research Labs (PRL)