From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7760 invoked by alias); 18 Apr 2012 15:16:14 -0000 Received: (qmail 7735 invoked by uid 22791); 18 Apr 2012 15:16:11 -0000 X-SWARE-Spam-Status: No, hits=-6.3 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 15:15:58 +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 q3IFFwHe025808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 Apr 2012 11:15:58 -0400 Received: from host2.jankratochvil.net (ovpn-116-78.ams2.redhat.com [10.36.116.78]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q3IFFsDD008081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 18 Apr 2012 11:15:57 -0400 Date: Wed, 18 Apr 2012 15:16: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: <20120418151553.GA16768@host2.jankratochvil.net> References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <4F832D5B.9030308@redhat.com> <20120409190519.GA524@host2.jankratochvil.net> <4F833D29.4050102@redhat.com> <20120416065456.GA30097@host2.jankratochvil.net> <4F8ECB72.70708@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F8ECB72.70708@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-04/txt/msg00114.txt.bz2 On Wed, 18 Apr 2012 16:10:58 +0200, Pedro Alves wrote: > On 04/16/2012 07:54 AM, Jan Kratochvil wrote: > > They are and they should not be, this is what archer-jankratochvil-vla with > > dynamic types is there for and which are not well maintainable without C++. > > I don't even know how to begin to respond to that. :-) The symbols side is perhaps > the part of a debugger that needs the most care about memory, and where you'll > most likely to see the need for POD types, and lower level handling of > memory, like the bcache. This is the current wrong approach where (a) CUs are expanded fully, not just the one or few symbols one started expanding that CU for. (b) CUs are expanded needlessly, such as during -expansion, there are more cases I did not analyze. And then with 99% of symbols not needed at all one tries to optimize every bit out of each symbol to make the 100% total size bearable... Just because everything is statically accessed and the expansion cannot be easily done on-demand when one accesses the fields by using getters everywhere. I can't believe we do not agree on such basic way forward. As one of the many examples the current main_type is unbelievable, I would not think it is possible to create something so bizarre, it could be sure fixed by redesigning it even in C (one big union with all fields specific per type and not just generic fields each overloaded differently for each type). But then we would end up with GTK - it has the right design but it is still C++-in-C, I hope everyone agrees GTK is wrong. Regards, Jan