From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15628 invoked by alias); 19 Jan 2010 16:15:25 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 15617 invoked by uid 22791); 19 Jan 2010 16:15:24 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Message-ID: <4B55DA8A.30307@redhat.com> Date: Tue, 19 Jan 2010 16:15:00 -0000 From: Chris Moller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Tom Tromey CC: Project Archer Subject: Re: vtable? References: <4B4F5C02.8020909@nc.rr.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2010-q1/txt/msg00023.txt.bz2 On 01/14/10 15:10, Tom Tromey wrote: > Chris> One of my guesses of the moment is that under the circumstances of the > Chris> bug, the "vtable" is either being built wrong or is somehow being > Chris> corrupted--does anyone have a clue where the "vtable" is built? > > From what I understand, gdb doesn't actually use the dwarf stuff to > build the class' vtable. There is a bug report or two in gcc bugzilla > about this; I gather that gcc doesn't emit all the needed info. > > So, rather than rely on the dwarf, gdb encodes knowledge of the ABI. > What appears to be happening is that when you try to print the base class [p *(D*)e], build_gdb_vtable_type in gnu-v3-abi.c gets called to set up a top-level type struct containing, among other stuff, a field tagged "vcall_and_vbase_offsets" that, so far as I can tell, contains nothing useful--i.e., it's empty. Later, in gnuv3_baseclass_offset, when the vtable is accessed for that field, it still appears to be empty. In fact, it hasn't been touched at all--the numeric values of the pointers, and all the other fields, are the same as they where when initialised. If gdb is supposed to be using knowledge of the ABI to build that field, it isn't. So the question is whether the right thing to do is fix the gdb a priori information hack, or to fix gcc (if necessary--a DWARF dump of the testcase shows a lot of information concerning all of the relevant classes, but whether it's right or sufficient I don't know) and fix gdb properly to use the DWARF info. Chris