From: Tom Tromey <tom@tromey.com>
To: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
Cc: Stephan Rohr <stephan.rohr@intel.com>,
Simon Marchi <simark@simark.ca>,
tom@tromey.com
Subject: Re: [PATCH 1/1] gdb/dwarf2: Fix 'rw_pieced_value' for values casted to different type.
Date: Fri, 14 Oct 2022 12:28:49 -0600 [thread overview]
Message-ID: <875ygmmf8e.fsf@tromey.com> (raw)
In-Reply-To: <0895de32-0b1b-4053-7a90-21d12fe81b6a@simark.ca> (Simon Marchi via Gdb-patches's message of "Fri, 19 Aug 2022 12:39:43 -0400")
>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
Simon> I'm trying to understand a bit better what happens here. The current
Simon> assertion states that it's incorrect to have a lazy value where the type
Simon> does not match the enclosing_type (I don't really know why)
I'm not 100% sure either, but I imagine the logic is that to have a
different enclosing type, gdb must have examined the value, dug through
its vtable, and found the true runtime type. But if this happened, then
the value can't be lazy any more.
Simon> So my question is: when doing the value cast, do we also want to
Simon> overwrite the value's enclosing type, in addition to the value's type?
Simon> Is it useful to retain the original enclosing type?
I think leaving it alone is probably wrong and could possible give other
weird results.
Tom
prev parent reply other threads:[~2022-10-14 18:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-22 14:44 [PATCH 0/1] " Stephan Rohr
2022-04-22 14:44 ` [PATCH 1/1] gdb/dwarf2: " Stephan Rohr
2022-06-06 16:51 ` Bruno Larsen
2022-07-14 7:50 ` Rohr, Stephan
2022-07-21 12:21 ` Rohr, Stephan
2022-08-02 6:30 ` Rohr, Stephan
2022-08-11 7:09 ` Rohr, Stephan
2022-08-19 7:41 ` Rohr, Stephan
2022-08-19 16:39 ` Simon Marchi
2022-10-11 8:03 ` Rohr, Stephan
2022-10-21 17:06 ` Tom Tromey
2022-10-14 18:28 ` Tom Tromey [this message]
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=875ygmmf8e.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.ca \
--cc=stephan.rohr@intel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).