From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17234 invoked by alias); 18 Apr 2012 20:11:10 -0000 Received: (qmail 17223 invoked by uid 22791); 18 Apr 2012 20:11:09 -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,SPF_HELO_PASS,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; Wed, 18 Apr 2012 20:10:52 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3IKAqqO017581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 Apr 2012 16:10:52 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3IKAoOl032652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 18 Apr 2012 16:10:51 -0400 From: Tom Tromey To: Pedro Alves 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> <4F832D5B.9030308@redhat.com> Date: Wed, 18 Apr 2012 20:11:00 -0000 In-Reply-To: <4F832D5B.9030308@redhat.com> (Pedro Alves's message of "Mon, 09 Apr 2012 19:41:31 +0100") Message-ID: <87d374pzqt.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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/msg00136.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> If you asked me not too long ago, I'd have been strongly in favor Pedro> of C++. However, that is no longer the case. I'm now pending Pedro> towards "no C++". First, let me say, thanks for your considered opinion. I'm sorry it has taken me so long to reply, but various personal events have made it hard to do so in a more timely way. Luckily (?) the thread rages on, so I don't feel too awfully tardy. Pedro> Indeed, gdbserver would need to remain pure C, and likewise any Pedro> code shared between gdbserver and gdb should have to be kept Pedro> as such. This is important, because we want gdbserver to be usable Pedro> in #1, resource constrained scenarios where the C++ dependency would Pedro> be unacceptable. I found this post to be sensible and I basically agreed with everything you said -- I'm sort of dog-like and easily swayed by the last thing I saw -- but on reflection I think the above paragraph is the crux of the argument, and I am not sure I agree with it. I think this relies on the idea that the C++ runtime dependency is unavoidably very heavy. And, in earlier discussions on the Archer list, I agreed with this idea without giving it too much thought. But, that seems to me to be an empirical question. We could measure the impact. This would mean having some criteria for what is acceptable. I think that would probably be a good thing to have. It seems weird that the current status is that code goes into gdbserver without any sort of measurement impact -- if resources are an issue, then they should be an issue generally, not just due to the specter of C++. Pedro> (On a sidenote: I get the impression from some that C++ would be mostly Pedro> useful for the stronger static typing, but I can't help finding it in Pedro> contrast with the simultaneous push of some of GDB functionality towards Pedro> being implemented in python, with duck typing and all, which people Pedro> are happy with. The two programming environments are very different, though; and the core-versus-extension difference is essential. One thing I like about scripting gdb in Python is that I can write quickly -- but also that I can write lower-quality code without caring about it. Pedro> One (uninvestigated) idea I had was to take a look at Linux's Pedro> sparse tool for catching issues like the "offsets" case that led Pedro> to this thread.) For the offsets case it might have worked; but in many interesting cases static analysis (and thus modification) of gdb is just crazily hard, because gdb is written in such a weird way. E.g., read the Coverity reports sometime -- tons and tons of false reports due to cleanups. Cleanups are hard to even check when you write a tool specifically for checking them (I did this...). They are also what will make it very difficult for us to use the Python refcount checker (we probably just won't). Pedro> There's also the issue with in-process code, which is also Pedro> desirable to remain as C code. Latest developments push towards Pedro> having debugger code run _within_ the inferior. Witness Pedro> gdbserver's current IPA (in-process agent; libinproctrace.so), Pedro> which has a lot of coupling in its implementation (and a lot of Pedro> code shared), and a bunch of code shared with gdbserver. We Pedro> can't predict which bits of GDB will we want to be able to reuse Pedro> in GDBserver or an IPA, but I do believe that we will be Pedro> considering it (reuse something more) the future. It seems to me that we must have a licensing issue here. Can it really be ok to map GPL'd code into any old process? It seems mildly absurd to me to couple the implementation language choice of a large, complicated, interactive host-side tool like gdb to that of an in-process debug agent. Tom