From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21559 invoked by alias); 27 Nov 2001 04:38:20 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21511 invoked from network); 27 Nov 2001 04:38:18 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 04:38:18 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 8A3C75E9D8; Mon, 26 Nov 2001 23:39:34 -0500 (EST) To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/c++] Fix printing classes with virtual base classes References: <20011126201945.A27754@nevyn.them.org> From: Jim Blandy Date: Tue, 13 Nov 2001 18:02:00 -0000 In-Reply-To: Daniel Jacobowitz's message of Mon, 26 Nov 2001 20:19:45 -0500 Message-ID: X-Mailer: Gnus v5.3/Emacs 19.34 X-SW-Source: 2001-11/txt/msg00263.txt.bz2 I'm with you on VALUE_OFFSET and VALUE_EMBEDDED_OFFSET. I'm pretty sure VALUE_OFFSET can be eliminated from GDB entirely, with some minor changes to the representation of subvalues of registers and convenience variables. Can you explain exactly what TYPE_VPTR_FIELDNO means, and how it works in heavily derived classes? What I think you're basically doing there is taking the address of the field indicated by TYPE_VPTR_FIELDNO, casting that to a void *, and then casting that to the `struct gdb_gnu_v3_abi_vtable' type. I have this vague memory that maybe using TYPE_VPTR_FIELDNO correctly would fix that. I wonder if that dereferencing code could be simplified with a judicious use of `lookup_pointer_type (vtable_type)' and `value_deref'... From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/c++] Fix printing classes with virtual base classes Date: Mon, 26 Nov 2001 20:38:00 -0000 Message-ID: References: <20011126201945.A27754@nevyn.them.org> X-SW-Source: 2001-11/msg00478.html Message-ID: <20011126203800.VwB6ducPsKFeisRLt-4eSWpmbqpoh1v0oKqGPojwFSs@z> I'm with you on VALUE_OFFSET and VALUE_EMBEDDED_OFFSET. I'm pretty sure VALUE_OFFSET can be eliminated from GDB entirely, with some minor changes to the representation of subvalues of registers and convenience variables. Can you explain exactly what TYPE_VPTR_FIELDNO means, and how it works in heavily derived classes? What I think you're basically doing there is taking the address of the field indicated by TYPE_VPTR_FIELDNO, casting that to a void *, and then casting that to the `struct gdb_gnu_v3_abi_vtable' type. I have this vague memory that maybe using TYPE_VPTR_FIELDNO correctly would fix that. I wonder if that dereferencing code could be simplified with a judicious use of `lookup_pointer_type (vtable_type)' and `value_deref'...