🚀 go-pugleaf

In article <20941.625010978@ics.uci.edu> rfg@ICS.UCI.EDU writes:
    
             The "GNU Linker" Approach
             -------------------------
	     A very different means of getting g++ up on COFF systems
	     has been implemented primarily by Dirk Grunwald
	     (grunwald@cs.colorado.edu).  I appologize if there were
	     other people (in particular, MDT) who also worked on this,
	     and who I have failed to give proper credit to.  In any
	     case, the "GNU Linker" approach is prefered by Michael
	     Tiemann and by the FSF because it uses fewer non-free
	     software tools.  This approach relies on a program call ed
    
MDT writes:

	 Another reason I prefer this approach is because linking need
	 only be performed once.  Using other approaches require the
	 link to be performed at least twice: once to figure out what
	 is needed, and once to then link in code which performs the
	 initialization.

rfg comments:

    Which "other approaches" are you refering to?  The "AT&T Linker"
    approach I described only does *one* link step.  Are there yet more
    approaches that I should have mentioned also?

Ron Guilmette described TWO approaches; actually there are FOUR, of which THREE
are used with COFF:


AOUT with the GNU ld++

	The GNU ld++ will scan the .o files as it links them and will
	generate the proper magic to activate the constructor and
	destructor lists.

COFF with the GNU ld++

	You must use gas and robotussin to generate COFF encapsulation
	.o files, that is files that have a COFF header but an AOUT
	body; gas will do the trick from .s files, robotussin from
	existing .o and .a files; once this has done you can still use
	GNU ld++, that will essentially ignore the COFF header and only
	deal with the AOUT body, reducing the problem to the previous one.

COFF with collect

	You generate .o files using the native System V assembler in
	COFF format; you link them with their C++ libraries, and scan
	them collect that will generate the appropriate
	contructor/destructor lists, then you link these with the
	result of the previous link and with the C libraries.

COFF with .ini .fini

	The System V linker can generate two sections of object, .ini
	and .fini, that contain initialization/termination code for the
	executable. You can modify G++ so that it puts static
	constructor/destructor calls in these sections, and then the
	standard System V assembler, linker and crt?.o will take care
	of everything.


These are orthogonal to the problem of symbol table style (there are
three, DBX, GDB, SDB), which is what mainly holds back GDB (as
apparently GDB can scan happily both COFF and AOUT objects)..

	 But I suppose if you are afflicted with COFF (or its related
	 diseases), the time spent linking is among the least of your
	 overall computer problems.

    I cannot (and do not) disagree that COFF is a "disease".  I do
    prefer a less drastic "cure" however. :-)

There are two executable file formats: traditional AOUT and COFF. For
some reason RMS has decided that GNU will use AOUT. COFF is actually
vastly more flexible. There are also several alternative symbol table
formats, as well. Time to link is a damn nuisance. COFF is a *good
thing*.

    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.

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), 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).

Apparently they have found in part their way into 1.36 (which I don't
have yet, so I don't know for sure).
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk