Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!paperboy!meissner From: meissner@osf.org (Michael Meissner) Newsgroups: comp.sys.encore Subject: Re: Questions regarding: Mach Release 1.0 for the Multimax Message-ID: Date: 20 Feb 91 21:18:09 GMT References: <14033@encore.Encore.COM> <3507@casbah.acns.nwu.edu> <14083@encore.Encore.COM> <3649@casbah.acns.nwu.edu> <14091@encore.Encore.COM> <3713@casbah.acns.nwu.edu> <14103@encore.Encore.COM> Sender: news@OSF.ORG Organization: Open Software Foundation Lines: 56 In-reply-to: boykin@encore.com's message of 20 Feb 91 17:02:28 GMT In article <14103@encore.Encore.COM> boykin@encore.com (Joseph Boykin) writes: | In article <3713@casbah.acns.nwu.edu>, phil@eecs.nwu.edu (William LeFebvre) writes: | |> |> Why would you care what object file format we use? Unless you have | |> |> another machine with the same instruction set (unlikely on an NS32K based | |> |> system!) with a different object file format, what's the difference? | |> | |> Kyoto Common Lisp cares. gcc cares. gdb cares. | | Several people pointed out via both email and news about public domain | tools. The reason I didn't comment about them was because several | people have ported those tools to Mach in the past. Some releases | are harder to port than others (the guy here who tried to port the | latest g++ never finished it), but the release before that was | a relatively small effort. Gdb has been ported to Mach by several | groups, including CMU (I think CMU will provide you with a multi-threaded | version of GDB). GCC itself has no problems with COFF. | I acknowledge that this may be a problem, but so far, there haven't | been too many problems porting things to Mach. Note that we don't | do very much different with COFF than e.g. Umax4, so I'm not sure | why there is a problem there either. In either case, news isn't | the forum for discussing the problem. The main problem with COFF is in the debugging support. Off of the top of my head, the problems are: 1) You cannot have code in include files (each object module can only have one .file directive) -- parser generators in particular get bitten by this, since they use #line directives to switch between the parser skeleton file, and the .y file containing the user's actions; 2) You cannot debug inline functions, even if they come from the same source file, since line numbers must be >= to the first line number inside of a function; 3) Standard COFF has no means of handling void, void *, const, volatile, or long double types; 4) Forward references to structure tags cause some problems, and references to completely unknown tags cause even more problems; 5) No support for more than 6 levels of *, (), or [] for a given declaration; 6) No support for nested functions, ala PASCAL. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?