From owner-freebsd-arch Tue Jun 20 18:35:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 346E937B868 for ; Tue, 20 Jun 2000 18:35:39 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id SAA01766; Tue, 20 Jun 2000 18:35:27 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpdAAAuRaiBd; Tue Jun 20 18:35:21 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id SAA09792; Tue, 20 Jun 2000 18:35:22 -0700 (MST) From: Terry Lambert Message-Id: <200006210135.SAA09792@usr01.primenet.com> Subject: Re: Plans to change our debugging format to DWARF2 To: peter.jeremy@alcatel.com.au (Peter Jeremy) Date: Wed, 21 Jun 2000 01:35:22 +0000 (GMT) Cc: asmodai@wxs.nl (Jeroen Ruigrok/Asmodai), arch@FreeBSD.ORG In-Reply-To: <00Jun21.062526est.115228@border.alcanet.com.au> from "Peter Jeremy" at Jun 20, 2000 06:23:49 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >I'd say go for it. But of course we want to MFC this to 4.x as well > >some point in the future. Along with all the other compiler changes. > > Why? This strikes me as a major change to a critical part of the > system - well beyond what I would expect to see in -stable. > > Somewhat over a year ago (from memory) there was an extended debate > about upgrading from gcc2.7.2.2 to gcc2.8.1 or ECGS. At that time > there was substantial resistance to the change - on the basis that > the behaviour of gcc2.7.2.2 was well understood. Whilst ECGS (and > later gcc2.95) were merged into 4-current, it was never MFC'd back > to 3.x. Actually, my reasoning had to do with templates and the additional overhead for non-threaded programs, if threaded programs were ever to be supported vs. the inability to support threaded programs if the overhead was removed. The GCC code had a dynamic mechanism for per thread exception stacks, which did not have the additional overhead, unles one was actually using threads in C++. The reason the current ACAP code can not be compiled on FreeBSD, and the reason the STL threads primitive classes do not work as expected, as well as the recent linker problems involving the FreeBSD "ld", in combination with template class errors, are all attributable to the move to EGCS. Too bad EGCS has not caught up with GCC + the patches by Jeremy Allison and myself from over a year ago... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message