From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5414 invoked by alias); 11 Apr 2003 10:12:27 -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 5380 invoked from network); 11 Apr 2003 10:12:12 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 11 Apr 2003 10:12:12 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h3BACCe18288 for ; Fri, 11 Apr 2003 06:12:12 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h3BACBW05199 for ; Fri, 11 Apr 2003 06:12:11 -0400 Received: from cygbert.vinschen.de (vpn50-50.rdu.redhat.com [172.16.50.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h3BACA524156 for ; Fri, 11 Apr 2003 03:12:10 -0700 Received: (from corinna@localhost) by cygbert.vinschen.de (8.11.6/8.9.3/Linux sendmail 8.9.3) id h3BAC7f27589 for gdb-patches@sources.redhat.com; Fri, 11 Apr 2003 12:12:07 +0200 Date: Fri, 11 Apr 2003 10:12:00 -0000 From: Corinna Vinschen To: gdb-patches@sources.redhat.com Subject: [RFA] cp-valprint.c::cp_print_class_method(): Use actual type in call to unpack_pointer Message-ID: <20030411101207.GD1928@cygbert.vinschen.de> Reply-To: gdb-patches@sources.redhat.com Mail-Followup-To: gdb-patches@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-SW-Source: 2003-04/txt/msg00230.txt.bz2 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. Corinna 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