From: CRDGW2::CRDGW2::MRGATE::"SMTP::PREP.AI.MIT.EDU::INFO-G++-REQUEST" 21-OCT-1989 19:51 To: MRGATE::"ARISIA::EVERHART" Subj: Re: Please describe how to use g++/gdb with COFF Received: by life.ai.mit.edu (4.0/AI-4.10) id AA07106; Sat, 21 Oct 89 17:21:41 EDT Return-Path: <rfg@ics.uci.edu> Received: from ICS.UCI.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA07093; Sat, 21 Oct 89 17:20:48 EDT Date: Sat, 21 Oct 89 14:15:01 PDT From: rfg@ics.uci.edu Subject: Re: Please describe how to use g++/gdb with COFF To: info-g++@prep.ai.mit.edu Message-Id: <8910211415.aa19148@ICS.UCI.EDU> In a recent posting, rjk@sequent.UUCP (Robert Kelley) writes: >I know that there are several approaches for using g++ and gdb with COFF. >One could modify g++ to generate assembler directives suitable for a COFF >assembler. One could translate assembler directives from a.out style to >COFF style. One could translate object files from a.out to COFF. There >are probably many other approaches. The ones that I would consider viable >would retain the ability to debug g++ programs with gdb. > >I would like to hear about any work in this area. Discussion of the relative >advantages and disadvantages of each approach would be particularly welcome. Actually, there appear to be two primary means of targeting the G++ compiler to a COFF based system, and zero (implemented) ways of getting gdb to fully understand the resulting executable files (but I may be wrong about this). The "AT&T linker" Approach -------------------------- As far a G++ targeting for COFF, I implemented one (simple?) method about a year ago. When I was working on the problem, I was targeting for NS32xxx processor. At that time, there was no implementation of either GAS or GNU ld available for the NS32xxx processors. Thus, in order to avoid having to port these tools myself, I decided to use the "native" assembler and linker (if possible). This is exactly the way most ports of GCC started life, i.e. most GCC ports started out assuming the use of a "native" assembler and linker. Because there was already a set of GCC configurations files for the NS32xxx processors (developed by Michael Tiemann, with minor patches specific to NSC's Genix OS added by me) the first cut of the G++ port was easy and (mostly) worked well. There was one important gotcha however. The "gotcha" was that my global objects were not being constructed before "main()" was called. Likewise, these objects were not being destructed upon program exit. I managed to figure out exactly why this problem occured, and I also managed to trick my (standard AT&T style) COFF linker into doing the tricky things that needed to be done to get the global constructors and destructor to execute. I (and others) have since managed to use the exact same techniques to get other standard AT&T COFF linkers (on several other machines and architectures) to do the same magic. Ron Cole (cvms!ronald@ucdavis.edu) has been distributing and maintaining my patches (for the "AT&T linker" approach) for some time now. He currently has complete patch kits for several recent versions of G++ (up to 1.35.1). I am now trying to bring up G++ 1.36.0- on the iPSC2 (aka Intel HyperCube) using this "AT&T linker" approach, and I will gladly make the revised patch set available as soon as they appear to be working. For more technical details regarding this approach, get the patches from Ron Cole (or via ananymous FTP from cindy.csuchico.edu in the ~ftp/pub directory) and read the file README.COFF (contained in the patch kit). 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 called "collect" which does some of the magic which the standard linker does in the "AT&T Linker" approach. It also requires the GNU assembler (aka GAS) which creates only a.out style object files. Finally, this approach relies on another program called "robotussin" (aka COFF medicine) which does a thing called COFF ENCAPSULATION. This turns a.out style object files into COFF object files. I cannot comment in too much detail on this approach because... well... I have never really used it. Perhaps Dirk will give us a short overview here. Pro's & Con's ------------- Fow awhile there, Dirk, and Ron Cole, and I and (to a lesser extent) Michael Tiemann were arguing back and forth in these newsgroups about which method is better. I believe that this discussion ultimately disintegrated into a "tastes great... less filling... tastes great... less filling...." type of argument. Nobody was being convinced of the validity of anybody else's point of view, so I (for one) decided not to bother anymore. Now, I would like to just make the point that (believe it or not) different people have different needs. Some people want a total GNU environment and they are willing to do all the porting work necessary to get there. Other people just want to bring up g++ (on their COFF based systems) with a minimum of muss and fuss. Both sets of needs are valid and, IMHO both sets of needs should be accomodated. As far as pros and cons of each approach, well, I feel that the AT&T Linker approach can be ported more easily (actually quite trivially) to most standard COFF based systems (there are one or two exceptions where individual manufacturers have strayed from the path of the one true COFF). I'm sure that Dirk will disagree with my statement, and claim that collect is more portable. If you have time, I suggest that you try both (and report your results here of course). Regarding support, Dirk G., Michael Tiemann, and the FSF are supporting the GNU linker approach. Ron Cole is trying his best to make the patches for the AT&T linker approach available to all who want them. Since Michael Tiemann has technical reservations about this approach, he is naturally unwilling to fully embrace the patches which implement it. Since it seems unlikely that MDT will incorporate these patches (ever) Ron Cole may get tired of hasseling with them at some point in time, and may decide to kiss it off. Thus, if you are worried about the very long haul, I suggest that you use the GNU linker approach. If, on the other hand, you want a quick (and not so dirty) implementation of G++ on your (standard) COFF system, I suggest that you try the AT&T Linker route. One final point. The last time I heard, the GNU linker could not yet deal with COFF shared libraries. If you need to use such libraries in your G++ programs, perhaps you had better use an AT&T linker. GDB Debugging ------------- Regarding the use of GDB on a COFF system for symbolically debugging G++ programs, if you can find anybody who has implemented this, I would very much like to hear about it!!!! As far as I know, this has simply never been implemented yet. // rfg