Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Corinna Vinschen <vinschen@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: [RFA] cp-valprint.c::cp_print_class_method(): Use actual type in call to unpack_pointer
Date: Fri, 11 Apr 2003 10:12:00 -0000	[thread overview]
Message-ID: <20030411101207.GD1928@cygbert.vinschen.de> (raw)

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


             reply	other threads:[~2003-04-11 10:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-11 10:12 Corinna Vinschen [this message]
2003-04-13 16:00 ` Daniel Jacobowitz
2003-04-14  8:48   ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030411101207.GD1928@cygbert.vinschen.de \
    --to=vinschen@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox