From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17157 invoked by alias); 31 Dec 2006 22:40:53 -0000 Received: (qmail 17149 invoked by uid 22791); 31 Dec 2006 22:40:52 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sun, 31 Dec 2006 22:40:46 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H19MB-0007RK-GB; Sun, 31 Dec 2006 17:40:43 -0500 Date: Sun, 31 Dec 2006 22:40:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sourceware.org Subject: Re: [c++] Pointer to member overhaul Message-ID: <20061231224043.GA28190@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sourceware.org References: <20061229025509.GA29152@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) 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: 2006-12/txt/msg00429.txt.bz2 Thanks for looking over it. On Fri, Dec 29, 2006 at 11:06:21AM -0800, Jim Blandy wrote: > The comments in cp-abi.h refer to 'cplus_method_ptr_to_target', which > isn't defined anywhere. Fixed, thanks. > The sentence "CONTENTS is the bytes forming the pointer to method" > isn't grammatical. Actually I disagree. CONTENTS is a singular noun here, the pointer whose name is "contents". > What is the use of TYPE_CODE_METHOD now? Is it equivalent to > TYPE_CODE_FUNC, except that it expects a 'this' pointer? It's basically the same as TYPE_CODE_FUNC. I eliminated a number of cases which treated them differently. dwarf2read uses the distinction to figure out what's a member pointer, but it could check for TYPE_CODE_FUNC too. There's some bits in infcall mostly dealing with argument promotion. It looks like it would be possible to remove TYPE_CODE_METHOD now - it wouldn't be hard, just require careful attention to detail. > Is the representation of a pointer to a data member always simply an > offset from the start of the member pointer's class? It would be nice > if the comment for TYPE_CODE_MEMBERPTR said this; similarly, it would > be nice if the comment for TYPE_CODE_METHODPTR explained that the > representation varies from one ABI to the next, and one should use the > cp-abi.h methods to work with them. Say the word, and I'll write > these for you. The only supported representation for TYPE_CODE_MEMBERPTR is the GNU v3 one, which is an offset and -1 for NULL. It varies by compiler, but I did not add support for any other representation, since the only thing already present was aCC and that support is on its way out. I added some words. > Why are vtable_function_descriptors and vbit_in_delta gdbarch methods > instead of cp-abi.h methods? Because they don't depend on the ABI, they depend on the architecture. Itanium sets vtable_function_descriptors but PowerPC64 doesn't. ARM and MIPS set vbit_in_delta since they need the low bit (for Thumb / MIPS16). -- Daniel Jacobowitz CodeSourcery