From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16472 invoked by alias); 9 Apr 2012 18:41:56 -0000 Received: (qmail 16464 invoked by uid 22791); 9 Apr 2012 18:41:54 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_TJ,T_RP_MATCHES_RCVD 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; Mon, 09 Apr 2012 18:41:34 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q39IfXd1022145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 9 Apr 2012 14:41:33 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q39IfVsF011930; Mon, 9 Apr 2012 14:41:32 -0400 Message-ID: <4F832D5B.9030308@redhat.com> Date: Mon, 09 Apr 2012 18:41:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Tom Tromey CC: Jan Kratochvil , gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++ or not? References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> In-Reply-To: <87aa2rjkb8.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00063.txt.bz2 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++". 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 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++. This, above, mainly #1, made me spend the last few days thinking about the "to C++ or not to C++" dilema, and I ended up concluding that C++ may not be a good idea afterall. 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 ). Another set of code that could also be shared, and thus would need to remain C is the ser*.c files. The ser_ops vector is one of those bits that would be "obvious" candidates for turning into C++ classes, but given the desire to reuse, it would need to stay C. The event-loop.c file is yet another thing. It is currently duplicated (though a bit simplified) in gdbserver/event-loop.c. There goes another use for C++ classes. The "monitor foo" commands are implemented completely by the target. E.g., try "monitor help" in gdbserver. GDBserver's implementation of monitor commands is ad hoc. This mechanism isn't transparent to GDB and users. E.g., completion can't work with these commands. I have desired before to rip out GDB's command registration machinery under cli/, making it more modular, and reusing it in GDBserver. There goes another big potential user for C++-fication. And then, there's the exceptions support. GDBserver's current error handling is like GDB's was 10 years ago. There's a simple setjmp at the top level, and any error longjmp's there. The debugging session tends to gets broken when an "error" happens This is even more likely to happen with multi-inferior debugging. As such, and with the gdb -> gdbserver backend merging in mind, it'd be desirable to make gdbserver's backends use GDB's TRY_CATCH and friends too. GDB's backends already do... Now, if parts of GDB are written in C++, which will be made to throw/catch C++ exceptions, we end up with the case that we need to wrap cross-language calls in both directions, in order to bridge/wrap the incompatible exceptions mechanisms. IMO, this is a _worse_ state than having the whole of the GDB core in C, and having everything and everyone speak the same language. The target_ops vector is yet another candidate for sharing between native gdb and gdbserver. Currently in gdbserver, linux-low.c calls into thread_db.c directly, while in the native debugger the flow is reversed. Even if the target vector ends up being replaced by some other form of chaining, it'd be very desirable to use the same mechanism in either the native debugger or gdbserver. So this means that the target_ops vector is something else that is probably not good to consider converting to C++ classes, although it always shows up high on the list of candidates. And I'm sure I could come up with other examples of things that would be nice C++ classes, but, we better not make them so. We can't really tell at this point what could or not be C++-ified freely, and I'd hate it to see some code converted to C++, only to end up needing to fork it and convert it to C down the road. Or worse, rewrite it from scratch. (On a sidenote: I get the impression from some that C++ would be mostly useful for the stronger static typing, but I can't help finding it in contrast with the simultaneous push of some of GDB functionality towards being implemented in python, with duck typing and all, which people are happy with. One (uninvestigated) idea I had was to take a look at Linux's sparse tool for catching issues like the "offsets" case that led to this thread.) 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. 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. -- Pedro Alves