From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 418A83858D28 for ; Fri, 6 Jan 2023 19:22:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 418A83858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [172.16.0.64] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 7EC111E110; Fri, 6 Jan 2023 14:22:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1673032937; bh=15xzS1vjthsZJSGnvaVwWo6FlIWRByzQLCyiLqucoQU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=CTcQEvHCIBoxMTLqMvbSwhRbBvb9kyOzHvp1FY2aD7V+3ddhnxLAOss82zkOehGGP 48KEHbNj4S4Io4zFcwxl0uVdrgNlEFcjEpXHqgEUNExj5Fo9kyogW4OfhkJB6whlJN 3hPs595JD1NotDSXfQofTWV/ANMydqmAxpPVk0II= Message-ID: <1007a4fe-75d7-76e0-2922-5e1f1dba4952@simark.ca> Date: Fri, 6 Jan 2023 14:22:16 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v3 1/1] gdb/dwarf2: Fix 'rw_pieced_value' for values casted to different type. Content-Language: fr To: Tom Tromey , Stephan Rohr via Gdb-patches Cc: Stephan Rohr References: <20221221131244.1287706-1-stephan.rohr@intel.com> <20221221131244.1287706-2-stephan.rohr@intel.com> <875ydkep2i.fsf@tromey.com> From: Simon Marchi In-Reply-To: <875ydkep2i.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 1/5/23 14:52, Tom Tromey wrote: >>>>>> Stephan Rohr via Gdb-patches writes: > >> From: "Rohr, Stephan" >> The 'rw_pieced_value' function is executed when fetching a (lazy) >> variable described by 'DW_OP_piece' or 'DW_OP_bit_piece'. The >> function checks the 'type' and 'enclosing_type' fields of the value >> for identity. > > Thanks for the patch. > >> If a lazy value is fetched, GDB allocates space based on the enclosing >> type's length and typically reads the 'full' object. This is not >> implemented for pieced values and causes an internal error if 'type' >> and 'enclosing_type' of a value are not identical. > >> However, GDB can read the value based on its type. Thus, this patch >> fixes the previously mentioned cases by removing the check for identity. > > I thought there was some other discussion & idea about the cause of this > patch... something like, setting a value's type should reset the > enclosing type? Or vice versa? I am wondering if you tried this > approach instead. For reference, here was my last attempt at understanding what happens: https://inbox.sourceware.org/gdb-patches/dd04b3b4-ea6a-07ba-d734-0e542ca136b3@simark.ca/ I don't have a strong opinion on the matter, I don't know if one solution is more corrent than the other. The thing is, I can't explain the logic behind the existing assert. It's missing a comment explaining why it would be a bad thing to "create a lazy value with an enclosing type". If we can't add such a justification, I think it's ok to remove it... Simon