From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23015 invoked by alias); 14 Dec 2007 20:37:20 -0000 Received: (qmail 22993 invoked by uid 22791); 14 Dec 2007 20:37:19 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Dec 2007 20:37:10 +0000 Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id lBEKb2iZ002785 for ; Fri, 14 Dec 2007 20:37:03 GMT Received: from rv-out-0910.google.com (rvbl15.prod.google.com [10.140.88.15]) by zps36.corp.google.com with ESMTP id lBEKaxRX018357 for ; Fri, 14 Dec 2007 12:37:02 -0800 Received: by rv-out-0910.google.com with SMTP id l15so953072rvb.20 for ; Fri, 14 Dec 2007 12:37:01 -0800 (PST) Received: by 10.141.186.12 with SMTP id n12mr2171102rvp.238.1197664621827; Fri, 14 Dec 2007 12:37:01 -0800 (PST) Received: by 10.141.142.4 with HTTP; Fri, 14 Dec 2007 12:37:01 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 20:44:00 -0000 From: "Doug Evans" To: gdb-patches@sourceware.org Subject: Re: [RFA] patch for 2384, dangling TYPE_VPTR_BASETYPE In-Reply-To: <20071214002920.GA1208@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071214002920.GA1208@caradoc.them.org> X-IsSubscribed: yes 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: 2007-12/txt/msg00197.txt.bz2 On Dec 13, 2007 4:29 PM, Daniel Jacobowitz wrote: > On Thu, Dec 13, 2007 at 04:10:55PM -0800, Doug Evans wrote: > > Ok to check in? Or any suggestions for what's needed instead? > > Your patch seems strange to me. Do we need the new fieldno / > basetype, or not? If we don't, we shouldn't be calculating it at all; > if we do, there should be something detectable which breaks when you > do this. It's not just a cache, since the interface doesn't offer any > other way to return the new fieldno / basetype besides in-place > modification. For the test case in the patch, type info for the derived class is left as opaque/stub, and when the vptr is needed check_typedef is called which notices the fact that is has an incomplete type and does a lookup by name to get the complete typo info. In this case check_typedef notices it has a cross-objfile reference and returns a pointer to the complete type info without updating the original type. This way cross-objfile pointers don't get created and the required data is still obtained when needed. There are other use cases. If base and derived are both in the same compilation unit then dwarf2read.c will fill in TYPE_VPTR_{BASETYPE,FIELDNO} (and presumably stabsread.c but I don't know offhand), and fill_in_vptr_fieldno is a nop. Another use case is if base and derived are in different compilation units but in the same objfile. Here dwarf2read.c will leave the base class as a stub for derived's type info. Later when vptr is needed fill_in_vptr_fieldno is called and it will notice fieldno < 0 and call check_typedef on the base type. check_typedef will see that orig_type and newtype are in the same objfile and will call make_cv_type to update the original type with the complete type info. > I happen to know that for GNU v3 - which is in practice the only thing > that any GDB users use nowadays - we don't need these fields any more. > We still use them, but we could do without, since the ABI is quite > clear on where to find the vtable pointer. > > For GNU v2, which is theoretically still supported, we do need this > information. Clearly fill_in_vptr_fieldno can't create cross-objfile pointers. All callers of fill_in_vptr_fieldno (should) expect that it may fail. I'm not quite sure what you're suggesting, as it relates to the patch. The v3 abi still needs logic to handle cross-objfile references, though it could be done without the use of fill_in_vptr_fieldno.