From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10716 invoked by alias); 1 Aug 2008 15:05:51 -0000 Received: (qmail 10706 invoked by uid 22791); 1 Aug 2008 15:05:48 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 01 Aug 2008 15:05:22 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KOwBz-0002Z5-Kr for gdb@sources.redhat.com; Fri, 01 Aug 2008 15:05:19 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Aug 2008 15:05:19 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Aug 2008 15:05:19 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: Move GDB to C++ ? Date: Fri, 01 Aug 2008 15:05:00 -0000 Message-ID: References: <487658F7.1090508@earthlink.net> <20080801131312.GA14712@caradoc.them.org> <200808011352.m71Dq1iY027637@brahms.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00014.txt.bz2 Mark Kettenis wrote: >> X-Spam-Check-By: sourceware.org >> Date: Fri, 1 Aug 2008 09:13:12 -0400 >> From: Daniel Jacobowitz >> >> On Thu, Jul 31, 2008 at 09:42:28PM +0300, Eli Zaretskii wrote: >> > > From: Vladimir Prus >> > > Date: Thu, 31 Jul 2008 10:10:37 +0400 >> > > >> > > I think this discussion went a bit wrong way -- trying to convince folks that >> > > *investing effort* in converting to C++ is justified. However, I don't think >> > > the proposal is about making folks not interested in C++ doing any work -- the >> > > proposal is about allowing folks who do some specific work, and want to make >> > > use of additional features C++ provides, to use those features, while not imposing >> > > significant problems on the rest of contributors. >> > >> > Your being busy refactoring does impose a significant problem on me. >> > We are members of the same team, so how you use your time while on the >> > team is important to me. >> >> Could you please expand on this idea? >> >> Certainly the event of refactoring will have a big impact on all >> contributors. That's at the moment of commit, and not before. So if >> you think it's actively harmful, that's a different issue from the >> one Vladimir is talking about here. >> >> GDB is a GNU project, driven by volunteers and sponsored contributors. >> And the sponsored contributors are volunteers from the perspective of >> anyone outside the sponsoring organization. I don't understand the >> objection to other people choosing to invest effort on something, even >> if you think it's unimportant. Volunteer projects go where their >> volunteers want to take them! >> >> And I think one of the bit structural issues in GDB is that it's hard >> for even active volunteers to take it to new places. I want to make >> that easier. > > [ This is not directed at Daniel in particular, his message was just > happened to be a convenient one to reply to. ] > > Guys, can we please stop this! These discussions are now taking up > almost all the time I have to hack on GDB. I feel obliged to take > part in them because I see them as a threat for the platforms I care > about, and the way GDB is shipped on those platform. But I really > hate it. > > More concretely. On OpenBSD we build GDB as a native debugger on all > our platforms. Some of these platforms still use GCC 2.95.3, because > later versions are slower, have a bigger memory footprint and have > more bugs, at least as far as the C compiler is concerned. Others use > GCC 3.3.5 for much the same reason. This is unlikely to change soon, > especially if GCC is going to be rewritten in C++. Rewriting GDB in > C++ is bad news for those platforms because GCC 2.95.3 is not a very > good C++ compiler and ships with an outdated STL library. I don't > think exception handling works reliably on all these platforms. I believe that for GDB purposes, 2.95.3 is just fine. In fact, 2.95 is exactly the release where gcc's C++ support became OK. > Things will get even slower and will probably require more memory than > some of my machines have. Do you have exact value, or estimate, or how much the performance and memory consumption will suffer? - Volodya