From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: gdb@sources.redhat.com, gdb-patches@sources.redhat.com
Subject: RFA: Re: Funky code in gnuv2_virtual_fn_field
Date: Tue, 22 May 2001 14:16:00 -0000 [thread overview]
Message-ID: <npzoc513tk.fsf_-_@zwingli.cygnus.com> (raw)
In-Reply-To: <87u22e19kz.fsf@dynamic-addr-83-177.resnet.rochester.edu>
Daniel Berlin <dan@cgsoftware.com> writes:
> Jim Blandy <jimb@zwingli.cygnus.com> writes:
>
> > I'm looking at lines 112--118 in gnu-v2-abi.c:
> >
> > if (TYPE_TARGET_TYPE (context) != type1)
> > {
> > value_ptr tmp = value_cast (context, value_addr (arg1));
> > VALUE_POINTED_TO_OFFSET (tmp) = 0;
> > arg1 = value_ind (tmp);
> > type1 = check_typedef (VALUE_TYPE (arg1));
> > }
> >
> > This looks fishy to me. If we smash the POINTED_TO_OFFSET without
> > smashing the ENCLOSING_TYPE in a corresponding manner, and then we
> > indirect through that pointer, don't we get a value whose
> > ENCLOSING_TYPE is set, but whose address points to the embedded
> > object, and not the enclosing object?
>
> Yup.
> However, although it's not documented anywhere, value_cast
> approriately smashes the enclosing type.
That's what I was afraid of. (I *hate* it when GDB does something
with a `struct value' that isn't really legal, but just happens to be
okay because we know internal details about where that `struct value'
came from...)
> IMHO, in any case, we shouldn't be needing to set the
> pointed_to_offset here. If we have to, value_cast is doing something
> wrong, or not enough of the right thing.
> This is because all we are trying to do is a simple cast, which is what
> value_cast is supposed to do for us. If we have to start mucking
> around with it's results to get a correct value, then it's not doing
> it's job right, or completely.
Great. So how about this patch?
2001-05-22 Jim Blandy <jimb@redhat.com>
* gnu-v2-abi.c (gnuv2_virtual_fn_field): There's no need to clear
VALUE_POINTED_TO_OFFSET here; if value_cast doesn't return a
useful value, then we should fix that instead.
Index: gdb/gnu-v2-abi.c
===================================================================
RCS file: /cvs/src/src/gdb/gnu-v2-abi.c,v
retrieving revision 1.2
diff -c -r1.2 gnu-v2-abi.c
*** gdb/gnu-v2-abi.c 2001/05/12 04:01:16 1.2
--- gdb/gnu-v2-abi.c 2001/05/22 21:14:35
***************
*** 111,117 ****
if (TYPE_TARGET_TYPE (context) != type1)
{
value_ptr tmp = value_cast (context, value_addr (arg1));
- VALUE_POINTED_TO_OFFSET (tmp) = 0;
arg1 = value_ind (tmp);
type1 = check_typedef (VALUE_TYPE (arg1));
}
--- 111,116 ----
next parent reply other threads:[~2001-05-22 14:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20010520160159.3484E5E9DB@zwingli.cygnus.com>
[not found] ` <87u22e19kz.fsf@dynamic-addr-83-177.resnet.rochester.edu>
2001-05-22 14:16 ` Jim Blandy [this message]
2001-05-23 21:24 ` Daniel Berlin
2001-05-25 10:10 ` Jim Blandy
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=npzoc513tk.fsf_-_@zwingli.cygnus.com \
--to=jimb@zwingli.cygnus.com \
--cc=dan@cgsoftware.com \
--cc=gdb-patches@sources.redhat.com \
--cc=gdb@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