From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9191 invoked by alias); 21 Apr 2004 18:43:38 -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 9149 invoked from network); 21 Apr 2004 18:43:36 -0000 Received: from unknown (HELO faui10.informatik.uni-erlangen.de) (131.188.31.10) by sources.redhat.com with SMTP; 21 Apr 2004 18:43:36 -0000 Received: from faui1d.informatik.uni-erlangen.de (faui1d [131.188.31.34]) by faui10.informatik.uni-erlangen.de (8.9.3p3/8.1.9-FAU) with ESMTP id UAA29529 for ; Wed, 21 Apr 2004 20:43:34 +0200 (CEST) From: Ulrich Weigand Received: (from weigand@localhost) by faui1d.informatik.uni-erlangen.de (8.9.3p3/8.1.6-FAU) id UAA26279 for gdb@sources.redhat.com; Wed, 21 Apr 2004 20:43:34 +0200 (CEST) Message-Id: <200404211843.UAA26279@faui1d.informatik.uni-erlangen.de> Subject: C++ pointer-to-member handling broken? To: gdb@sources.redhat.com Date: Wed, 21 Apr 2004 18:44:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-04/txt/msg00125.txt.bz2 Hello, it looks like the handling of C++ pointers to members is broken at the moment; the assumptions GDB makes about how these data structures are layed out by the compiler do not match what any (recent) GCC does ... Two issues that are currently causing testcase failures on s390x: - For pointer to data members, GDB assumes (in cp_print_class_member (cp-valprint.c)) that these are of type 'int' and hold the byte offset. This is incorrect on s390x (and other 64-bit platforms): they should by of type 'ptrdiff_t' (which is 'long') according to the GCC 3.x C++ ABI. Note that GDB is even incompatible with itself here: in value_struct_elt_for_reference (valops.c), when it generates a pointer-to-data-member value, they are stored as *addresses* (e.g. 64-bit). This causes a test case failure on s390x-ibm-linux: FAIL: gdb.cp/classes.exp: print Bar::z - For pointer to member functions, GDB needs to be aware of how the compiler distinguishes between virtual and non-virtual member functions. This is currently done using these macros in 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)) This does not adhere to the GCC 3.x ABI on any platform, which uses a pair of (address or vtable offset) and this-adjust delta, where virtual functions are marked either by the *low* bit of the address, or by the low bit of the delta, depending on whether the platform supports functions starting at odd addresses or not. On s390(x), the low bit of the address is used, while this test checks the high bit. Thus, virtual functions are not detected correctly. Even worse, on s390x the default starting address of executables is 0x80000000. This means that *normal* functions are frequently misdetected as virtual; this causes the test case failure: FAIL: gdb.cp/printmethod.exp: print virtual method. Any suggestions how to fix this? I guess there should be some target interface that allows the target to define the format of pointers to members according to the platform's ABI ... Bye, Ulrich -- Dr. Ulrich Weigand weigand@informatik.uni-erlangen.de