Path: utzoo!utgpu!watmath!uunet!tut.cis.ohio-state.edu!gatech!ncar!boulder!grunwald
From: grunwald@foobar.colorado.edu (Dirk Grunwald)
Newsgroups: gnu.g++
Subject: Re: Please describe how to use g++/gdb with COFF
Message-ID: <13058@boulder.Colorado.EDU>
Date: 23 Oct 89 01:49:10 GMT
References: <8910212151.AA26599@lurch.Stanford.EDU>
	<20941.625010978@ics.uci.edu>
Sender: news@boulder.Colorado.EDU
Reply-To: grunwald@foobar.colorado.edu
Distribution: gnu
Organization: University of Colorado at Boulder
Lines: 30
In-reply-to: rfg@ICS.UCI.EDU's message of 21 Oct 89 22:09:38 GMT


Ron asks ``are there other alternatives that I didn't mention'' & the
answer is `yes'.

Namely, collect & native assembler/linker. In this combination, you
compile your programs using g++ & assemble using your native linker.
The g++ frontend is changed to do two links. The first link builds a
relocatable binary. You then run ``collect'' over this binary to
generate a .s file containing the ctor/dtor list. This file is
assembled & your original (mostly resolved) binary is linked with the
final .s file.

You now have a complete binary with ctor/dtor information. This is
similar the `munch' approach used in AT&T C++.

The advantages of this over e.g., using the COFF link directives file
is that it's more portable. You can use the same mechanism on the MIPS
assembler/linker, where it's not clear if you *have* linker files
(ifiles, I think they're called). The disadvantage is you link twice,
but that hasn't appeared to be much of a bottleneck.

Mark Linton uses a similar approach, but uses an `awk' script and `nm'
to get the output.

btw, collect.c was recently modified - someone is trying to get it work
on the 386i -- if anyone else has gotten this to work, please mail me
patches. I think I know what needs doing, but don't have a 386i. In any
case, look for patches on monday.

Dirk Grunwald -- Univ. of Colorado at Boulder	(grunwald@foobar.colorado.edu)