From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17065 invoked by alias); 10 Apr 2012 00:23:37 -0000 Received: (qmail 17056 invoked by uid 22791); 10 Apr 2012 00:23:35 -0000 X-SWARE-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Apr 2012 00:23:15 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SHOrZ-0001dw-MC from Yao_Qi@mentor.com ; Mon, 09 Apr 2012 17:23:13 -0700 Received: from SVR-ORW-FEM-02.mgc.mentorg.com ([147.34.96.206]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Apr 2012 17:23:01 -0700 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.1.289.1; Mon, 9 Apr 2012 17:23:12 -0700 Message-ID: <4F837D4C.4050901@codesourcery.com> Date: Tue, 10 Apr 2012 00:23:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Pedro Alves CC: Tom Tromey , Jan Kratochvil , Subject: Re: Will therefore GDB utilize C++ or not? References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <4F832D5B.9030308@redhat.com> In-Reply-To: <4F832D5B.9030308@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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-04/txt/msg00069.txt.bz2 On 04/10/2012 02:41 AM, Pedro Alves wrote: > Indeed, gdbserver would need to remain pure C, and likewise any > code shared between gdbserver and gdb should have to be kept > as such. This is important, because we want gdbserver to be usable > in #1, resource constrained scenarios where the C++ dependency would > be unacceptable. We don't want there to need to be other gdbserver-like > programs specialized for such environments, and gdbserver to be usable only > on bigger machines. We want gdbserver to run everywhere. And #2, the debugger I agree. The system configure or capability of embedded devices are diversiform, from tiny piece of memory to multiple giga-bytes of memory. GDBserver fits to low-end devices. Even nowadays, the size of GDBserver increases as more functionalities added, we should avoid GDBserver depends on C++ libraries. > is one of the first programs that is desirable to get running on a new > system/board. Usually you get C going much sooner than C++. > Yes, when building up a system on a board, GDBserver is usually the "first class" programs to build. > > I'm very wary that introducing C++ will make it increasingly > difficult to share between the C++ and C parts. Currently not > that much is shared between gdb and gdbserver, but it is long desired, > and in actually in this year's plan to merge gdb's and gdbserver's > backends (am I am actively working on this. See > ). Agree. We have multiple codes to share among GDB and GDBserver, this will reduce the scope of GDB C++-fication. > There's also the issue with in-process code, which is also > desirable to remain as C code. Latest developments push towards having > debugger code run _within_ the inferior. Witness gdbserver's current IPA > (in-process agent; libinproctrace.so), which has a lot of coupling in its > implementation (and a lot of code shared), and a bunch of code shared with > gdbserver. We can't predict which bits of GDB will we want to be able to > reuse in GDBserver or an IPA, but I do believe that we will be considering > it (reuse something more) the future. > As GDBserver and in-process agent becomes more and more powerful (which is the trend of debugging, IMO), they will share more and more code with GDB. For example, when supporting ITSET in GDBserver and in-proc agent, even the design is not mature, it shows that we need move some bits of GDB to gdb/common, and share with GDBserver and in-proc agent. > So all in all, I believe that in a C++ world, GDB's "C++ in C" wouldn't > really go away; it would end up still being prominent, not as hidden as > libbfd or other dependencies. Not hidden enough that we could just > tuck it under the carpet. I worry that this actually makes it _worse_ > for new contributers, who will need to learn about GDB's C idiomatic usage, > and whatever new C++ idiomatic usage GDB would end up with. With that, and > the worry about the new source of trouble and bugs and confusion that > it would be the bridging between the parts written in the different languages, > I do believe we're better off staying in C land, at least for a couple years more. In short, I am not against using C++ in GDB. -- Yao (齐尧)