From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20272 invoked by alias); 16 Feb 2010 22:25:32 -0000 Received: (qmail 20254 invoked by uid 22791); 16 Feb 2010 22:25:31 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_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; Tue, 16 Feb 2010 22:25:26 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o1GMPOB0004666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 16 Feb 2010 17:25:25 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o1GMPOmI012166; Tue, 16 Feb 2010 17:25:24 -0500 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o1GMPN3U020476; Tue, 16 Feb 2010 17:25:23 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id D14D7379956; Tue, 16 Feb 2010 15:25:22 -0700 (MST) From: Tom Tromey To: Chris Moller Cc: gdb-patches@sourceware.org Subject: Re: beta patch for PR 9065 References: <4B7AE477.9060606@redhat.com> Reply-To: tromey@redhat.com Date: Tue, 16 Feb 2010 22:25:00 -0000 In-Reply-To: <4B7AE477.9060606@redhat.com> (Chris Moller's message of "Tue, 16 Feb 2010 13:31:19 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-02/txt/msg00406.txt.bz2 >>>>> "Chris" == Chris Moller writes: Chris> [Question: Internally, this patch is based on "sizeof" which actually Chris> creates an int type that, in addition to just being printed, can be Chris> used for stuff like "set = sizeof()". The gdb typeid Chris> doesn't even try to create an analogue to a type_info class, it just Chris> extracts the name from the appropriate type struct and creates a Chris> cstring type from it. Would it be good/essential for the Chris> implementation to instantiate a real type_info class? (That, I Chris> suspect, will be a lot more work...)] I think it is reasonably important to find the type_info. Anything else will yield results which violate the "cut and paste" rule. E.g., the user might have a function that takes a `const type_info&' argument. It may be reasonable to require the user to have libstdc++ debuginfo installed in order for this to work. I would accept this as a first patch (with the usual caveat that if new information arises, etc). IIRC, the type_info object is stored in some vtable slot in the v3 ABI. If that is in fact the case then we probably want a new cp-abi function for this. In this situation, IMO it is ok for the v2 variant to throw an exception (or not be implemented, same difference). One additional possible gotcha is making sure that gdb gives a sensible error message if the user compiled with -fno-rtti. Chris> + {"typeid", TYPEID, OP_NULL, 0}, This is a C++ keyword, so the last field should be 1, not 0. Chris> +static struct value *evaluate_subexp_for_typeid_type (struct expression *, int *); Chris> +static struct value *evaluate_subexp_for_typeid_var (struct expression *, int *); The new style is to put static functions above their uses so we don't have to have forward declarations. Tom