From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13852 invoked by alias); 22 Nov 2012 18:46:47 -0000 Received: (qmail 13844 invoked by uid 22791); 22 Nov 2012 18:46:47 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Nov 2012 18:46:42 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAMIkgmC022170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 22 Nov 2012 13:46:42 -0500 Received: from host2.jankratochvil.net (ovpn-116-39.ams2.redhat.com [10.36.116.39]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qAMIkbDe013809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 22 Nov 2012 13:46:40 -0500 Date: Thu, 22 Nov 2012 18:46:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: Tom Tromey , gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++ or not? Message-ID: <20121122184637.GA29474@host2.jankratochvil.net> References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <4F832D5B.9030308@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F832D5B.9030308@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2012-11/txt/msg00067.txt.bz2 On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote: > If you asked me not too long ago, I'd have been strongly in favor > of C++. However, that is no longer the case. I'm now pending > towards "no C++". I have re-read now the thread and I have not found any blocker issues left. Here is a plan that should IMHO satisfy all the requirements stated here. I did not reply to C++ disagreements which were already well enough replied here. Current gdbserver will be also in C++. For most embedded Linux kernel targets it will be enough to build the standard fully featured gdbserver with static libstdc++ (making it only ~2x larger). There will be also separate minimal gdbserver in plain C. For some very minimal targets still running Linux kernel but no longer having C++-capable compiler or having some other problem running C++. There was stated no concrete such target but maybe there exists one. This minimal server has no need for non-stop/multi-inferior etc., it will be created by stripping down the current one; but in fact one can be also easily code it from scratch. libinproctrace.so will remain in C so far. I do not think this sole reason should block the GDB + gdbserver move to C++. In the future I believe it can move to statically built libstdc++ without problem. It will never be supported on the minimal C gdbserver which also is not a problem. There should be provided a list of systems GDB needs to remain compatible with and which are available for login directly or which can be at least promptly regression tested upon request. As could be seen for example on Solaris recently the compatibility with a system which GDB is not tested against will break. The compatibility is not kept automatically just thanks to the reviews. Then we can find out the minimal C++ level can be required. I assume some -std=c++98 with a bundled subset of Boost should be OK. Thanks, Jan