🚀 go-pugleaf

Summary:
      I desparately need to hear from anyone who has gotten Emacs (any
      version) running on an Amdahl UTS 2.1 system with Expanded
      Fundamental Types (EFT).

System:
      Amdahl 5990 running UTS 2.1, with Extended File System
Emacs: 
      GNU Emacs 18.57.27 of Wed May 15 1991 on ecfa (usg-unix-v)
      GNU Emacs 18.54.1 of Tue Jan  9 1990 on ecfuts (usg-unix-v)

Problem 1:
      Users unable to open certain files on Extended File System (EFS)
      with Emacs 18.54.  All of the "afflicted" files all have i-nodes
      greater than 65535.

Information:

      From the _UTS System Technical Overview_ manual:

  The EFS is a specialized file system, designed to take advantage of
  the 370-XA architecture and to overcome the traditional drawbacks
  of the UNIX file systems.  EFS increases speed, throughput, reliability,
  and capacity...
  In order to take advantage of the EFS features, you may have to convert
  your applications to use EFT [Expanded Fundamental Types].
  ...
  Expanded Fundamental Types (EFT) is a feature of UTS Release 2.1 that
  allows the expansion of certain data types which have outgrown their
  original capacities.  Many system calls and header files are affected
  by this expansion. ...EFT satisfies a major requirement for the Extended
  File System (EFS), and provides extended major and minor device numbers.
  ...
  UTS Release 2.1 uses a version of Expanded Fundamental Types (EFT) based
  on UNIX System V, Release 4.0.

Attempted Solution:
      Convert Emacs 18.57 to use EFT.  Make Emacs with -eft flag to cc(1)
      to signify that this is an EFT-compatible program.

Problem 2 (with Attempted Solution):
      a) The dumped xemacs coredumps with Illegal Instruction Error on 
         launch.  Attempt to trace core dump fails; debugger says:
                 "fatal_error_signal(Text address not found"
      b) temacs -l loadup brings up a very sick Emacs with these symptoms:
         -- won't load (find-file) any files larger than ~4k bytes, gives
"IO error reading /aed/matthews/utils/emacs/eft1857/src/alloc.c: Bad address"
         -- after giving this message, it will give similar message for ALL 
            files
	 -- A "fresh" temacs (right after launch) will open small files
            (< ~4k), but have "garbage" starting about 2048 characters
            into the file.  Any attempt to move point more than a dozen
            lines or so into the "garbage" region results in a coredump 
            with the message: "Fatal error (6).Abort(coredump)"  This
            core dump, like the others, is untraceable.  A sample of
            the transition from "valid" to "garbage" text follows:
------------- begin excerpt from src/config.h-dist ---------------
/* #define X11 */

/* Define HAVE_X_MENU if you want to use the X window menu system.
   This appears to work on some machines that support X
   and not on others.  */

/* #define HAT^B^@^T^@^L\324 ^@
^K\350^@\377\336\363^C^G^Mp^C
\311 ^A \320^LprocT^B^@^T^@^L\324@^@^L\324^H^@\377\336\363^C^G^M\204^C
\311 ^A \320^Lyou T^B^@^T^@^L\324`^@^L\324(^@\377\336\363^C^G^M\230^C
\311 ^A \320^LnchrT^B^@^T^@^L\324\200^@^L\324H^@\377\336\363^C^G^M\254^C
\311 ^A \320^Led iT^B^@^T^@^L\324\240^@^L\324h^@\377\336\363^C^G^M\300^C
\311 ^A \320^L.
  T^B^@^T^@^L\324\300^@^L\324\210^@\377\336\363^C^G^M\324^C
-------------- end excerpt from src/config.h-dist ----------------
 
The expanded types affect many of the structs used in system calls; 
stat for example has several new members and the types of the existing
members have been expanded (i.e., st_size went from long to long long,
and st_ino went from ushort to ulong).  I have attempted to track down
the places where the EFT types may be colliding with whatever Emacs is
expecting, but I'm having a lot of difficulty wending my way through
the maze of twisty little macros, all alike, that confronts me in the 
source code.

Any hints, suggestions, pointers, or tips that anyone can give me would
be greatly appreciated; the help desk and sysadmin have been breathing
down my neck about this for two weeks (and starting to question the
wisdom of going with GNU instead of Unipress :-( ...)
---
Mike Matthews             matthews%ecfa@jesnic.jsc.nasa.gov
          (backup) -->           matthews@asd2.jsc.nasa.gov
          (if all else fails) -->            (713) 333-7079
Tethered Vehicle Analysis Group, Advanced Projects Section
Navigation, Control, and Aeronautics Department
Lockheed Engineering & Sciences Company, Houston, Texas