[RFA] cp-valprint.c::cp_print_class_method(): Use actual type in call to unpack_pointer

[RFA] cp-valprint.c::cp_print_class_method(): Use actual type in call to unpack_pointer

[Corinna Vinschen]

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  <vinschen@redhat.com>

	* 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, "<unknown>");
       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

Re: [RFA] cp-valprint.c::cp_print_class_method(): Use actual type in call to unpack_pointer

[Daniel Jacobowitz]

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  <vinschen@redhat.com>
> 
> 	* 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, "<unknown>");
>        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

Re: [RFA] cp-valprint.c::cp_print_class_method(): Use actual type in call to unpack_pointer

[Corinna Vinschen]

On Sun, Apr 13, 2003 at 12:00:47PM -0400, Daniel Jacobowitz wrote:
> 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  <vinschen@redhat.com>
> > 
> > 	* cp-valprint.c (cp_print_class_method): Call unpack_pointer() with
> > 	actually incoming type.

Thanks, applied.

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com