🚀 go-pugleaf

In article <GUMBY.91May16185726@Cygnus.COM> gumby@Cygnus.COM (David V.
Wallace) writes:

| 
|    Date: 16 May 91 14:47:44 GMT
|    From: cpetterb@glacier.sim.es.com (Cary Petterborg)
| 
|    I thought that there was not the support in gcc yet for additional debugging
|    information.  I understand that it is certainly possible, but that no one
|    had yet done it.  Has DEC made the necessary modifications to gcc to give
|    the "-g" debugging info?  If so, have they made the modifications available
|    yet, or when will they be made available?  Am I out in left field about the
|    "-g" support for the MIPS platform?
| 
| Meissner put support in for OSF/1's own debugging format, called Rose.
| It's different from the 3rd-eye format used by the MIPS compiler.

Let's see if I can straighten things out.

OSF/1 as delivered by the Open Software Foundation is a source
release.  We also provide three reference ports (DECstation 3100 using
the MIPS chip, Intel 386, and Encore Multimax using the National 32x32
chips).  The compiler used in all three platforms is GCC.  The object
file format that we use for the reference platforms is called
OSF/rose, which uses normal BSD-style stabs for debug information.
Modified versions of the GNU assembler, linker, and debugger are used
which understand OSF/rose.

The OSF/rose object file format is copyrighted in the manner of
X11/BSD (ie, you can use, don't nuke the copyrights), but obviously
you need to modify your system program loader to handle it.  At one
time, the FSF was interested in OSF/rose for use with the full GNU
system.  I don't know if they are still thinking of using it.

While I have no inside track as to what DEC ultimately releases as
it's OSF/1 release, I gathered from the press releases that it's
developer's release used the OSF/1 tools (ie, GCC and friends).  The
real release presumably would go back to using the standard DEC
compiler and ECOFF.

Before we switched to OSF/rose, I wrote an object file munger that
reads the assembly source which has the debug information passed as
comments, and the object file produced by the assembler.  The object
file munger then spits out a new object file, which has the debug
information inserted into it.  This is all necessary, because the MIPS
assembler used in Ultrix, does not have any method of creating the
necessary debug information for local variables.  I still fix the
occasional bugs in the object file munger, but it is now background
work.

Except for a few small patches to enable it, all of the work is now
installed into revision 2.00 of GCC.  When GCC 2.00 will be available
for general use, I haven't the foggiest idea.

As time permits, I put versions of the GCC sources onto the machine
foobar.colorado.edu, in the directory pub/Gnu-For-Pmax.  The current
files that are there include:

  total 12646
  drwxrwxrwx  3 0        system       1024 May 17 20:44 .
  drwxrwxrwx  8 0        system        512 May  1 18:09 ..
  drwxr-xr-x  2 ftp      system        512 May 17 20:46 2.0-mods
  -rw-rw-r--  1 11746    system       1021 Feb 12 21:21 README-g++-1.37.1
  -rw-rw-r--  1 11746    system       3270 Feb  4 09:10 README.G++
  -rw-r--r--  1 ftp      system      17148 Jan 28 12:32 collect.c
  -rw-r--r--  1 0        system    1721295 Nov 11  1990 g++-osf-1.9.2.11.tar.Z
  -rw-r--r--  1 0        system       8944 Nov 11  1990 gcc-1.8.1.5-Iris3.3.shar.Z
  -rw-r--r--  1 ftp      system     510215 Dec 15 10:34 gcc-fsf-1.37.1-osf-1.9.2.14.patch.Z
  -rw-r--r--  1 ftp      system     336419 Apr 16 16:52 gcc-fsf-1.39-osf-1.39.3.patches.Z
  -rw-r--r--  1 ftp      system      30390 Mar 13 13:11 gcc-osf-1.39.2-osf-1.39.3.patches.Z
  -rw-r--r--  1 ftp      system    2540357 Mar 13 13:46 gcc-osf-1.39.3.tar.Z
  -rwxrwxr-x  1 11746    system     681724 Apr 17 17:47 gdb-3.94.2.Z
  -rw-r--r--  1 ftp      system     558592 Apr 21 11:56 mips-gas.tar.Z
  -rw-r--r--  1 ftp      system      61643 Jan 30 08:40 mips-gdb-3.5-diffs.Z
  -rw-rw-r--  1 ftp      system     533246 Apr 26 14:03 osf_gas_V1.0-1.tar.Z
  -rw-rw-r--  1 ftp      system     300735 Apr 26 14:05 osf_gld_V1.1-0.tar.Z
  -rw-r--r--  1 0        system        553 Nov 11  1990 split.c
  -rw-rw-r--  1 11746    system    5510814 Apr 24 17:36 usr.local.gnu.tar.Z

In particular, gcc-fsf-1.39-osf-1.39.3.patches.Z is a set of patches
from FSF release 1.39 to my third OSF 1.39 release.  Obviously, these
are not offical FSF patches.  I also maintain a mailing list to be
notified when new patches come out.  Send me mail, if you want to be
on it.  Recently, the mailing list has been rather quiet.

Also note that Dirk Grunwald has provided patches for G++ 1.37 to be
used with my last set of 1.37.1 patches.  Dirk has been busy with his
own work, and also has said that there were problems with G++ 1.39 in
general, which is why there are no 1.39 patches.


Here is some dated information about G++:

The currently known bugs for G++ 1.37.1 are (12/15/1990):

   1)	The gcc.c in the g++ dump has an off-by-one problem, to fix
	it, replace it with the gcc.c from the GCC dump.

   2)	malloc.c doesn't work properly in libg++, specify the
	following in the Makefile:

		XTRAFLAGS = -DNO_LIBGXX_MALLOC

   3)	You must configure g++ with the following in Makefile:

		COFFFLAGS = -DUSE_COLLECT -DEXTENDED_COFF

	and the all target should be:

		all: g++ cc1plus collect # crt0+.o crt1+.o

   4)	G++'s Makefile doesn't run in subdirectories yet.

   5)	Ignore the messages (best as I can tell) about duplicate
	functions lmask__Fi, rmask__Fi, BSnew__Fi in libg++ -- these
	are inlines that aren't getting inlined.

   6)	The tFix and wrapper libg++ tests are known not to work.  I
	also had problems with tRandom.

   7)	Debugging isn't completely supported for G++ (it is for GCC).

   8)	Passing structures that are unaligned (ie, contain only shorts
	and/or chars) will not generate the correct code.


George Hartzell (hartzell@boulder.Colorado.EDU) and Peter Ham
(ham@cs.stanford.edu) were looking into better G++ debug support.

Here is a comment from Mike Iglesias:

I've been able to build g++ and libg++ under ultrix 4.1.  However, I
wasn't able to build groff v0.6 - I got the same seg fault.  I was
able to build groff v0.5 with no problems, and it seems to work fine
for what I've used it for so far (printing troff documents on a Postscript
printer).

[meissner comment: I seem to remember the segfault is caused in
dumping out the debug symbol table, if you don't compile for debugging
there was no segfault]

There are some problems with building libg++ - a couple of .h files
in g++-include are named wrong (LogNormal.h should be LogNorm.h, for
example).  You can apply the patch at the end of this message to
CursesW.h to get programs that use it (like the tCurses test) to
build properly.  I think the main thing to do when building libg++
is to not use the malloc that comes with libg++ (look in the Makefile
for how to use the Ultrix one).

As for g++, I don't remember having a lot of problems with it, but it
was a few weeks ago when I did it, so I may be forgetting something.
I followed Dirk Grunwald's directions (posted here a few weeks back).


Mike Iglesias
University of California, Irvine
Internet:    iglesias@draco.acs.uci.edu
BITNET:      iglesias@uci
uucp:        ...!ucbvax!ucivax!iglesias

*** CursesW.h.orig	Fri Jun 22 03:27:44 1990
--- CursesW.h	Sat Dec 29 10:10:48 1990
***************
*** 140,146 ****
--- 140,148 ----
    int            scroll();
    int            scrollok(cbool bf);
    int            touchwin();
+ #ifndef ultrix
    int            touchline(int y, int sx, int ex);
+ #endif
    int            refresh();
    int            leaveok(cbool bf);
    int            flushok(cbool bf);
***************
*** 151,157 ****
    int            overlay(CursesWindow &win);
    int            overwrite(CursesWindow &win);
  
! #ifndef DGUX
    int            touchoverlap(CursesWindow &win);
  #endif
  
--- 153,159 ----
    int            overlay(CursesWindow &win);
    int            overwrite(CursesWindow &win);
  
! #if !defined(DGUX) && !defined(ultrix)
    int            touchoverlap(CursesWindow &win);
  #endif
  
***************
*** 214,220 ****
    return ::scroll(w); 
  }
  
! #ifndef DGUX
  inline int CursesWindow::touchoverlap(CursesWindow &win)   
  {
    return ::touchoverlap(w, win.w); 
--- 216,222 ----
    return ::scroll(w); 
  }
  
! #if !defined(DGUX) && !defined(ultrix)
  inline int CursesWindow::touchoverlap(CursesWindow &win)   
  {
    return ::touchoverlap(w, win.w); 
***************
*** 296,305 ****
--- 298,309 ----
    return ::wmove(w, y, x); 
  }
  
+ #ifndef ultrix
  inline int CursesWindow::touchline(int y, int sx, int ex)
  {
    return ::touchline(w, y, sx, ex);
  }
+ #endif
  
  inline int CursesWindow::mvcur(int sy, int ey, int sx, int ex)
  {


Here is a posting from Per Bothner about GDB:

New patches to port gdb to MIPS-based machines (including
DECstations and SGI Iris) are now available by
anonymous ftp from sevenlayer.cs.wisc.edu (128.105.8.11)
in pub/mips-gdb-3.5-diffs.Z. Uncompress this file, and
then use patch applied to a virgin gdb-3.5 distibution.

The changes are minor, so don't bother if you already
have gdb running. The main differences are better support
for Ultrix 4.0, as well as support for SGI Iris core files
(thanks to David B.Anderson (davea@sgi.com)). (Also, this
time I remembered to give the -c option to diff!)

The gdb port uses native ECOFF object file format,
which is emitted by cc, gcc, and g++. Unfortunately,
ECOFF doesn't really support g++, so gdb won't be very
useful for g++ programs.

Gdb 4.0 will have mips support bundled in. Version 4.0
is being actively worked on, but needs major cleaning
up before it can be released.

	--Per Bothner
bothner@cs.wisc.edu Computer Sciences Dept, U. of Wisconsin-Madison


Here is a comment from Arne Henrik Juul

| From: Arne Henrik Juul <arnej@solan.unit.no>
| To: grunwald@foobar.colorado.edu, meissner@osf.org, minar@reed.bitnet
| Cc: h@solan.unit.no
| Subject: Problems with ../../conf/mips
| Date: Tue, 19 Feb 1991 05:57:03 +0100

To whom it may concern:

In the README.G++ file for public ftp on
foobar.colorado.edu, the following is reported:

...

> From: minar%REED.BITNET@CUNYVM.CUNY.EDU
> To: meissner@osf.org
> Subject: mips gcc and g++
> Date: Sun, 3 Feb 91 02:25:07 PST

...
 
> gcc/fixincludes:
>   the shell script failed on the directory "../../conf/mips"  I didn't pick
> the script apart, but at least on our machine there IS a directory
> "/usr/include/mips/conf" but no "/usr/include/conf/mips"

This is triggered by having /usr/include/machine a link to
/sys/machine/mips, and /usr/include/machine/conf a link to
../../conf/mips  which gives /usr/sys/conf/mips .... sigh.

In fixincludes there is a test whether a symlink is
'internal' in a tree or not. However, if the symlink starts
with ../ one may need to resolve the link. Quick fix:

*** orig/fixincludes	Sun Feb 17 00:38:59 1991
--- my/fixincludes	Tue Feb 19 05:19:01 1991
***************
*** 81,86 ****
--- 81,91 ----
  	rm -f ${LIB}/$file > /dev/null 2>&1
  	ln -s $dest ${LIB}/$file > /dev/null 2>&1
        else				# dont make links outside ${INC}
+ 	  hereweare=`pwd`
+ 	  if cd $file; then
+ 		dest=`pwd`
+ 	  fi
+ 	  cd $hereweare
  	  treetops="$treetops $dest ${LIB}/$file"
        fi
      fi



It's not a very good fix, since it only works for
directories, but it's late here in Europe... somebody will
surely see more clearly than I do.

I hope this may be a small contribution to your great work!

Yours,

    Arne H. Juul, arnej@lise.unit.no, student & system manager.

(I also read mail for gnu@solan.unit.no, if you mail there.)

--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.