From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alt-proxy28.mail.unifiedlayer.com (alt-proxy28.mail.unifiedlayer.com [74.220.216.123]) by sourceware.org (Postfix) with ESMTPS id 738093858023 for ; Fri, 14 Oct 2022 18:29:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 738093858023 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from cmgw13.mail.unifiedlayer.com (unknown [10.0.90.128]) by progateway1.mail.pro1.eigbox.com (Postfix) with ESMTP id EB2EB1003DF52 for ; Fri, 14 Oct 2022 18:28:55 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id jPQVouD5ktK4cjPQVoBoF3; Fri, 14 Oct 2022 18:28:55 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=HYLR8gI8 c=1 sm=1 tr=0 ts=6349aa67 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=Qawa6l4ZSaYA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=CCpqsmhAAAAA:8 a=Zh0F7OoToAAROF_yNL4A:9 a=ul9cdbp4aOFLsgKbc677:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=xK+Q3FveMK9KbHGrqFMD9e2taNAnxDrEyDAeqlb2r6E=; b=JR2sN3GaXvA+txUztrUjauTrAZ wyHd+kNyXClX0ve7x7xxcPUNERJVV9E399LD99TwfFWKmX/D/jk7VCcri6wIHRBFCHoEOnOQgWS3i C7O9opwzFPp6qZ7VKMbLs/VcH; Received: from 71-211-160-49.hlrn.qwest.net ([71.211.160.49]:56686 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1ojPQU-000N6A-Oq; Fri, 14 Oct 2022 12:28:54 -0600 From: Tom Tromey To: Simon Marchi via Gdb-patches Cc: Stephan Rohr , Simon Marchi , tom@tromey.com Subject: Re: [PATCH 1/1] gdb/dwarf2: Fix 'rw_pieced_value' for values casted to different type. References: <20220422144420.3545190-1-stephan.rohr@intel.com> <20220422144420.3545190-2-stephan.rohr@intel.com> <0895de32-0b1b-4053-7a90-21d12fe81b6a@simark.ca> X-Attribution: Tom Date: Fri, 14 Oct 2022 12:28:49 -0600 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") Message-ID: <875ygmmf8e.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 71.211.160.49 X-Source-L: No X-Exim-ID: 1ojPQU-000N6A-Oq X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 71-211-160-49.hlrn.qwest.net (murgatroyd) [71.211.160.49]:56686 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3022.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2022 18:29:07 -0000 >>>>> "Simon" == Simon Marchi via Gdb-patches 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