From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11198 invoked by alias); 27 Mar 2003 14:53:49 -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 11191 invoked from network); 27 Mar 2003 14:53:48 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 27 Mar 2003 14:53:48 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18yaep-0002rq-00 for ; Thu, 27 Mar 2003 10:55:15 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18yYlG-0001uT-00 for ; Thu, 27 Mar 2003 09:53:46 -0500 Date: Thu, 27 Mar 2003 14:53:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: Problem with virtual function pointers Message-ID: <20030327145346.GA7253@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <20030327142412.GK23762@cygbert.vinschen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030327142412.GK23762@cygbert.vinschen.de> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00370.txt.bz2 On Thu, Mar 27, 2003 at 03:24:12PM +0100, Corinna Vinschen wrote: > Hi, > > I'm just investigating a problem which XStormy16 gets in > gdb.c++/printmethod.exp: > > print theA->virt^M > $1 = invalid pointer to member function^M > FAIL: gdb.c++/printmethod.exp: print virtual method. > > It turned out that the error happens in xstormy16_pointer_to_address(). > This function converts an address to a jump table entry into a pointer > to the actual function. To do this, it calls a conversion routine, > which is only called if the following condition applies: > > > enum type_code target = TYPE_CODE (TYPE_TARGET_TYPE (type)); > > if (target == TYPE_CODE_FUNC || target == TYPE_CODE_METHOD) > convert(); > > Surprisingly (at least for me) this fails for the above case. Looking > into type, I found that type is TYPE_CODE_PTR which is correct, but > target_type is TYPE_CODE_VOID! Sure, the above virtual method is of > type void but is that really ok? Shouldn't that be > > type: TYPE_CODE_PTR > type->target_type: TYPE_CODE_METHOD > type->target_type->target_type: TYPE_CODE_VOID > > ? Could you give me a backtrace? > Does somebody know why that happens? Is that just a bug in gdb? Or > could that be related to incorrect debug info from gcc? I believe this has to do with the type info emitted for virtual function tables, but I need to see the backtrace to confirm. If so I'm not sure whether it's really a bug in GCC or GDB... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer