Epoch 3.2 on the DECstation

Thread View: gnu.epoch.misc

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by rak Thu, 28 Feb 1991 00:11

#2138

Author: rak
Date: Thu, 28 Feb 1991 00:11

46 lines
2474 bytes

I'm just now installing Epoch 3.2 here, and I caught only the tail end
of what seemed to be a discussion of the changes needed to get it
running on a DS3100 under Ultrix 3.1.  Could someone please send or
describe the necessary changes?  

I know about the need to change the null pointer test on line 99 of
xresource.c when DATA_SEG_BITS is defined, but this change does not
seem to be sufficient.

Using the m-pmax.h and s-bsd4-3.h, the make runs fine, though the
compiler generates a lot of warnings about the redefinition of
DATA_START, but compiles ok until "./temacs -batch -l inc-vers" hangs
with this backtrace:


>  0 make_uninit_string(length = 33) ["alloc.c":519, 0x44bb30]
   1 make_string(contents = 0x88bfe0 = "Warning: past 75% of memory
	   limit", length = 33) ["alloc.c":497, 0x44ba34]
   2 build_string(str = 0x88bfe0 = "Warning: past 75% of memory
	   limit") ["alloc.c":506, 0x44baa4] 
   3 malloc_warning(str = 0x88bfe0 = "Warning: past 75% of memory
	   limit") ["alloc.c":77, 0x44af38] 
   4 morecore(nu = 10) ["malloc.c":359, 0x4736a4]
   5 .block199 ["malloc.c":497, 0x473a64]
   6 malloc.malloc(n = 8184) ["malloc.c":497, 0x473a64]
   7 init_strings() ["alloc.c":458, 0x44b890]
   8 init_alloc_once() ["alloc.c":1427, 0x44d800]
   9 main(argc = 4, argv = 0x7fffeca4, envp = 0x7fffecb8)
	   ["emacs.c":377, 0x429264] 


In this configuration we have, from m-pmax.h,

#define DATA_START 0x10000000
#define DATA_SEG_BITS 0x10000000

and temacs seems to be hanging when init_strings() makes some
ridiculously large malloc request, triggering a warning that tries to
use the (not yet allocated) string space to compose its warning
message.

Anyway, I'd appreciate hearing how anyone who has gotten Epoch 3.2
working on a DS3100 did so...

Ed Rak
rak@gramian.harvard.edu

Re: Epoch 3.2 on the DECstation

#2141

Author: Chris Weikart
Date: Thu, 28 Feb 1991 15:58

146 lines
5442 bytes

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)

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads