From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4661 invoked by alias); 13 Apr 2003 16:00:54 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4653 invoked from network); 13 Apr 2003 16:00:53 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 13 Apr 2003 16:00:53 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 194juf-0002hQ-00 for ; Sun, 13 Apr 2003 11:01:02 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 194juS-0002l0-00 for ; Sun, 13 Apr 2003 12:00:48 -0400 Date: Sun, 13 Apr 2003 16:00:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFA] cp-valprint.c::cp_print_class_method(): Use actual type in call to unpack_pointer Message-ID: <20030413160047.GA10498@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20030411101207.GD1928@cygbert.vinschen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030411101207.GD1928@cygbert.vinschen.de> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00268.txt.bz2 On Fri, Apr 11, 2003 at 12:12:07PM +0200, Corinna Vinschen wrote: > Hi, > > according to the discussion on the gdb ML beginning with > http://sources.redhat.com/ml/gdb/2003-03/msg00369.html > I'm now proposing to change cp-valprint.c::cp_print_class_method() to > call unpack_pointer() with the actual type given to cp_print_class_method(). > > Rational: > > To unpack a pointer type it's often necessary to call target dependent > address translation routines. These routines sometimes have to know the > actual type of the datatype to do their job right. In case of XStormy16, > addresses to functions and methods *could* be pointers to entries in a > jump table. Since this is only valid for functions and methods, the > appropriate XStormy16 function checks the incoming datatype for being > TYPE_CODE_FUNC or TYPE_CODE_METHOD. > > The current implementation of cp_print_class_method() calls unpack_pointer() > always with a type `pointer to void'. This eliminates the necessary > type info of the incoming type. This obviously euchres target functions > trying to find the correct address by the pointer type. > > The below patch should work fine under all circumstances since > cp_print_class_method() is called from c_val_print only and only if type is > TYPE_CODE_METHOD. > > The patch eliminates a potential FAIL in gdb.c++/printmethod.exp: > > print theA->virt^M > $1 = invalid pointer to member function^M > FAIL: gdb.c++/printmethod.exp: print virtual method. This is OK. If we find somewhere that the incoming type is not a pointer then we can deal with it later. > 2003-04-11 Corinna Vinschen > > * cp-valprint.c (cp_print_class_method): Call unpack_pointer() with > actually incoming type. > > Index: cp-valprint.c > =================================================================== > RCS file: /cvs/src/src/gdb/cp-valprint.c,v > retrieving revision 1.19 > diff -u -p -r1.19 cp-valprint.c > --- cp-valprint.c 25 Feb 2003 21:36:17 -0000 1.19 > +++ cp-valprint.c 11 Apr 2003 09:53:09 -0000 > @@ -87,7 +87,7 @@ cp_print_class_method (char *valaddr, > fprintf_filtered (stream, ""); > return; > } > - addr = unpack_pointer (lookup_pointer_type (builtin_type_void), valaddr); > + addr = unpack_pointer (type, valaddr); > if (METHOD_PTR_IS_VIRTUAL (addr)) > { > offset = METHOD_PTR_TO_VOFFSET (addr); > > -- > Corinna Vinschen > Cygwin Developer > Red Hat, Inc. > mailto:vinschen@redhat.com > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer