From: Daniel Jacobowitz <drow@mvista.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [RFA] cp-valprint.c::cp_print_class_method(): Use actual type in call to unpack_pointer
Date: Sun, 13 Apr 2003 16:00:00 -0000 [thread overview]
Message-ID: <20030413160047.GA10498@nevyn.them.org> (raw)
In-Reply-To: <20030411101207.GD1928@cygbert.vinschen.de>
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
next prev parent reply other threads:[~2003-04-13 16:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-11 10:12 Corinna Vinschen
2003-04-13 16:00 ` Daniel Jacobowitz [this message]
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=20030413160047.GA10498@nevyn.them.org \
--to=drow@mvista.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