Path: utzoo!utgpu!watmath!uunet!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!usc!orion.oac.uci.edu!uci-ics!rfg
From: rfg@ics.uci.edu (Ron Guilmette)
Newsgroups: gnu.g++
Subject: Re: Please describe how to use g++/gdb with COFF
Message-ID: <1989Oct27.194302.25731@paris.ics.uci.edu>
Date: 28 Oct 89 02:43:02 GMT
References: <1444@aber-cs.UUCP>
Reply-To: Ron Guilmette <rfg@ics.uci.edu>
Distribution: gnu
Organization: University of California, Irvine - Dept of ICS
Lines: 49

In article <1444@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>
>Ron Guilmette described TWO approaches; actually there are FOUR, of which THREE
>are used with COFF:

I was speaking only of the number of approaches to get G++ up *only* on COFF
based systems.  So the correct number is three.  In any case, I stand corrected.

>COFF with the GNU ld++

>COFF with collect

>COFF with .init/.fini sections  (this is the AT&T linker approach)

>    P.S.  Can you comment on the shared library problem?  Is there
>    really a problem there, or was that just a rumor?
>
>The problem is that shared libraries under System V do have their own
>constructors and destructors; that is why COFF has .ini/.fini
>sections.  If you use the stock crt?.c file as in the G++ distribution,
>it will not activate these sections, and shared libraries will not
>work. It is actually fairly easy to add to the crt?.c file the required
>magic.

Right.  I have already done so to my version of crt0.c for G++.

>In the patches to G++ for SystemV/386 I posted some weeks ago there are
>ways to use the 'COFF with collect' way of doing things (I would have
>preferred doing the .ini/.fini trick, but that meant altering the
>compiler, as compared to altering the collect program, and I would not
>want to do that before the full 2.0 mods were done by MDT)...

The compiler changes are very minor and probably do not affect the parts
of the compiler that MDT is now working on.

>...and updates
>to crt?.c and System V ld scripts to support both shared libraries and
>its -z option (unmapping of the first 20K of virtual mem to catch stray
>null pointer dereferencing).

Changing crt0/1.c and adding a linker directives file are both trivial
(especially when the changes are already tested and available).  Most
linker directives files are only about 8 lines long.

Arguing that the AT&T linker approach involves too many changes is just plain
silly.  C'mon people!  We are only talking about a hundred lines or less of
patches!  This is getting ridiculous.  I guess that *anything* can be
characterized as being "too complicated" or "too risky" so long as you
don't really *want* to consider anybody's solution other than your own.