🚀 go-pugleaf

In article <1786@wrdis01.af.mil> jshumate@wrdis01.af.mil ( Shumate Jason) writes:

   There is a recent post in comp.sys.pyramid (it was NOT cross-posted to any
   GNU groups, hence this post) that says that GCC version 2.0 has not been
   ported to Pyramid's 90x architecture.  This is very distressing because

Oh yes, it's me again - now with Pyramids. I was the one who posted this.

   previous versions of GCC would work on the Pyramid.  G++ would never work
   on the Pyramid without extensive modification.  Essentially, what had 
   happened was that in older versions of Pyramid's operating system (OSx 4.4
   and below), the Pyramid assembler generated OMAGIC files by default.  GCC
   would run as is, but if you wanted to run G++, you had to use some patches
   written by a guy in New Zealand that totally replaced the stdarg/vararg
   implementation in GCC and G++.  Also, the linker had to be modified too.

Did you get the right mods from Jonathan? Some time ago I obly got a patch
from his ftp sever that contained some modifications for argument passing by
intoducing some new __builtin functions, but I never managed to get the
appropriate changes for stdarg/varargs.h from ("must dig it out from tape").

   Well, with OSx 5.0 and above, Pyramid's assembler now generates ZMAGIC files,
   but no version of any GNU linker can link G++ output this assembler produces.
   Version 2 was supposed to be our salvation and fix all our problems - now we
   must wonder if we'll ever see it run at all on our boxes.  The guy who made
   the patches for GCC and G++ no longer has a Pyramid to play with, and frankly,
   it's over my head.  I tried everything I could think of to get G++ to run
   under OSx 5.0, as did a guy I contacted in Australia, but we had no success.
   We were able to compile G++ and the library, but the linker never worked.

Funny, funny, November '90 I mailed a few patches for the ld++ of 1.37 to
bug-gcc@prep.ai.mit.edu (or so) and they appeared indeed in the newsgroup.
Our gcc-1.40 is running till day one with the (now old) GNU ld. The patches
are rather short, I'll add them below.

   Is anyone anywhere working on porting GCC version 2 (and G++) to Pyramid's
   90x family of computers?  If so, are they addressing the problems we have
   under OSx 5.0 and above?  A port that will only run under OSx 4.4 will do a
   lot of us absolutely no good, for reasons stated above.  I would be willing to
   help, but frankly, I'm not sure I have the technical knowledge to do very
   much.  Please cross-post any answers to comp.sys.pyramid as it is likely to

That is exact the problem. I do have access to an Assembler Ref. Manual, but
it's now pretty old. As the introduction of the ISIS assembler broke some the
old machine descriptions and Pyramid seems to keep a lot of internals as much
as possible secret, writing a new pyr.md /tm-pyr.h and so on is really not
trivial. I would spend a bit of my time to do it, but our three Targon 35 M50
(aka 9815 (9015) ???) are now only used as mail and NFS server. Development is
now entirely done on Sparcs.

Ok, now the patch. Beware: this is not for the new ld in binutils-1.94! If
some of new GNU ld authors would give me some suggestions where to place the
changes (correction of relocation and symbols values) best (BFD??), I could
invest a few days in it.

*****************************************************************************
Well, the reason for gld's failure is pyramids confusion about their object
file types. As most of you recall, there are OMAGIC, NMAGIC and ZMAGIC
executables. OMAGIC has contiguous text/data&bss, NMAGIC/ZMAGIC's data and bss
is aligned on the next memory page. Almost all assemblers spit out OMAGIC
files , but not Pyramids ! pyr-as creates NMAGIC files with split text&data
area (compile a VERY simple program with some global data and inspect via 'nm'
the symbol table : the data symbol will be somewhere around 0x800 = 2K =
PAGSIZ). This is the first reason that gld won't work. But now the best: If
you also examine crt0.o and libc.a, you will notice that most of the objects
are good old OMAGIC ones !! This is at least true for a TOS 3.3 on a TARGON
/35 ( approx. OSx 4.4).

And now the good News : patch follows. By the way, is anybody using GDB-3.5 on
pyrs and having problems with 'next' and other minor hassle ? I don't know if
my version is the newest, but I've also for gdb some patches. Please post a
request, don't mail (we have to pay for oversea mail !)

Note : the diff was made with ld.c from g++-1.37.1. The first chunks could
cause some trouble due to indentation.

*** ../test/g++-1.37.0/ld.c	Tue Feb  6 01:06:31 1990
--- ld.c	Tue Dec 18 19:21:47 1990
***************
*** 176,181
  #if defined(i386) && !defined(sequent)
  #define INITIALIZE_HEADER N_SET_MACHTYPE (outheader, M_386)
  #endif
  
  #ifdef is68k
  /* This enables code to take care of an ugly hack in the ISI OS.

--- 178,186 -----
  #if defined(i386) && !defined(sequent)
    #define INITIALIZE_HEADER N_SET_MACHTYPE (outheader, M_386)
  #endif
+ #if defined(pyr) || defined(pyramid)
+ #  define INITIALIZE_HEADER outheader.a_machid = PYR90X
+ #endif
  
  #ifdef is68k
    /* This enables code to take care of an ugly hack in the ISI OS.
***************
*** 2708,2713
  	    /* A symbol whose value is in the data section
  	       is present in the input file as if the data section
  	       started at an address equal to the length of the file's text.  */
  	    p->n_value += entry->data_start_address - entry->header.a_text;
  	    break;
  	  case N_BSS:

--- 2713,2729 -----
  	    /* A symbol whose value is in the data section
  	       is present in the input file as if the data section
  	       started at an address equal to the length of the file's text.  */
+ #ifdef pyr
+ 	  /* check if this is an NMAGIC object. if so, adjust data_start_adress
+ 	   * accordingly. (mj), cadlab 10/10/90
+        */
+ 	  if (entry->header.a_type.a_magnum == NMAGIC) {
+ 		  /* page aligned data+bss area */
+ 	    p->n_value += entry->data_start_address - 
+ 			  ((entry->header.a_text + page_size -1) & ~(page_size-1));
+ 	  }
+ 	  else
+ #endif
  	    p->n_value += entry->data_start_address - entry->header.a_text;
  	    break;
  	  case N_BSS:
***************
*** 2713,2718
  	  case N_BSS:
  	  case N_SETB:
  	    /* likewise for symbols with value in BSS.  */
  	    p->n_value += entry->bss_start_address
  	      - entry->header.a_text - entry->header.a_data;
  	    break;

--- 2729,2743 -----
  	  case N_BSS:
  	  case N_SETB:
  	    /* likewise for symbols with value in BSS.  */
+ #ifdef pyr
+ 	  /* the same for bss_start_address */
+ 	  if (entry->header.a_type.a_magnum == NMAGIC) {
+ 		  /* page aligned */
+ 	    p->n_value += entry->bss_start_address - entry->header.a_data -
+ 			  ((entry->header.a_text + page_size -1) & ~(page_size-1));
+ 	  }
+ 	  else
+ #endif
  	    p->n_value += entry->bss_start_address
  	      - entry->header.a_text - entry->header.a_data;
  	    break;
***************
*** 3693,3698
    int data_relocation = entry->data_start_address - entry->header.a_text;
    int bss_relocation
      = entry->bss_start_address - entry->header.a_text - entry->header.a_data;
  
    for (; p < end; p++)
      {

--- 3718,3733 -----
    int data_relocation = entry->data_start_address - entry->header.a_text;
    int bss_relocation
      = entry->bss_start_address - entry->header.a_text - entry->header.a_data;
+ #ifdef pyr
+   /* once again: NMAGIC ? adjust data & bss relocation ! (mj), cadlab 10/10/90 */
+   if (entry->header.a_type.a_magnum == NMAGIC) {
+ 	  /* page aligned data+bss area */
+ 	  data_relocation = entry->data_start_address - 
+ 		  ((entry->header.a_text + page_size -1) & ~(page_size-1));
+ 	  bss_relocation = entry->bss_start_address - entry->header.a_data -
+ 		  ((entry->header.a_text + page_size -1) & ~(page_size-1));
+   }
+ #endif
  
    for (; p < end; p++)
      {







--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Michael Joosten   |       Tel.  : (+49) (+) 5251-284 120                 |
| CADLAB            |       Fax   : (+49) (+) 5251-284 140                 |
| Bahnhofstr. 32    |       E-Mail: joost@cadlab.de                        |
| D-4790 Paderborn  |        	    ...!uunet!unido!cadlab!joost           | 
| FRG               | Mass mail to: joost@pbinfo.uni-paderborn.de          |
|--------------------------------------------------------------------------|
| CADLAB is a cooperation between Uni-GH Paderborn & SNI AG                |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~