From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31472 invoked by alias); 29 Nov 2004 14:43:19 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31374 invoked from network); 29 Nov 2004 14:42:59 -0000 Received: from unknown (HELO mtagate1.de.ibm.com) (195.212.29.150) by sourceware.org with SMTP; 29 Nov 2004 14:42:59 -0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id iATEgwug166916 for ; Mon, 29 Nov 2004 14:42:59 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iATEgsvQ133208 for ; Mon, 29 Nov 2004 15:42:54 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iATEgmsp020177 for ; Mon, 29 Nov 2004 15:42:48 +0100 Received: from d12ml068.megacenter.de.ibm.com (d12ml068.megacenter.de.ibm.com [9.149.164.163]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iATEgmC3019908; Mon, 29 Nov 2004 15:42:48 +0100 Subject: Re: METHOD_PTR_*? To: drow@false.org, cagney@gnu.org Cc: gdb@sources.redhat.com Message-ID: From: Ulrich Weigand Date: Mon, 29 Nov 2004 15:37:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-SW-Source: 2004-11/txt/msg00253.txt.bz2 Daniel Jacobowitz wrote: >On Tue, Nov 09, 2004 at 03:57:02PM -0500, Andrew Cagney wrote: >> Hello, >> >> From value.h: >> >> /* Pointer to member function. Depends on compiler implementation. */ >> >> #define METHOD_PTR_IS_VIRTUAL(ADDR) ((ADDR) & 0x80000000) >> #define METHOD_PTR_FROM_VOFFSET(OFFSET) (0x80000000 + (OFFSET)) >> #define METHOD_PTR_TO_VOFFSET(ADDR) (~0x80000000 & (ADDR)) >> >> It also depends on the underlying architecture - not very 64-bit >> friendly :-/ > >Yuck! > >If I'm reading this right, it corresponded to some old compiler's >implementation. But nowadays we fake it in >value_struct_elt_for_reference. This is a bit tricky to untangle, but >I think this could be solved entirely in eval.c (and the one place we >print "virtual" and ditching the remaining bits. I wonder if anything >in the testsuite exercises this? This is responsible for these testsuite failures on s390x-ibm-linux: FAIL: gdb.cp/classes.exp: print Bar::z FAIL: gdb.cp/printmethod.exp: print virtual method. (s390x tends to exercise this bug as the default load address for executables happens to be 0x80000000.) I don't think this can be handled entirely in eval.c; while there are some cases where gdb code itself sets up something like a pointer-to- member-function (which you could conceivably handle internally), you also need to be able to handle a *real* p-t-m set up by the target compiler. However, there doesn't appear to be any real testsuite coverage for that case. As the format of a pointer-to-member is defined by the platform ABI, I guess some sort of target callback would be appropriate. For GNU/Linux using GCC 3.x, the format is defined for IA64 at http://www.codesourcery.com/cxx-abi/abi.html#member-pointers and non-IA64 platforms use variants of that scheme; here's what the GCC internals doc has to say about it: `TARGET_PTRMEMFUNC_VBIT_LOCATION' The C++ compiler represents a pointer-to-member-function with a struct that looks like: struct { union { void (*fn)(); ptrdiff_t vtable_index; }; ptrdiff_t delta; }; The C++ compiler must use one bit to indicate whether the function that will be called through a pointer-to-member-function is virtual. Normally, we assume that the low-order bit of a function pointer must always be zero. Then, by ensuring that the vtable_index is odd, we can distinguish which variant of the union is in use. But, on some platforms function pointers can be odd, and so this doesn't work. In that case, we use the low-order bit of the `delta' field, and shift the remainder of the `delta' field to the left. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand Linux for S/390 Design & Development IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen Phone: +49-7031/16-3727 --- Email: Ulrich.Weigand@de.ibm.com