From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by sourceware.org (Postfix) with ESMTPS id DE25B3858016 for ; Fri, 15 Apr 2022 20:24:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DE25B3858016 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 cmgw11.mail.unifiedlayer.com (unknown [10.0.90.126]) by progateway3.mail.pro1.eigbox.com (Postfix) with ESMTP id 405C210047DB1 for ; Fri, 15 Apr 2022 20:24:53 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id fSUungsQXwm8ifSUvniCcw; Fri, 15 Apr 2022 20:24:53 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=DpSTREz+ c=1 sm=1 tr=0 ts=6259d495 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=z0gMJWrwH1QA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=vaw8AQdHcKMGAVAkkA4A:9 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=PaJW37n56S8OJlqHdMRTH5+DXRWNO8LZxdm2jRf9z7Y=; b=Yr9nmlf5M/gImKnkr3ESmAWHdJ 7JNZnoquDH3x8UrpV5yItnUhXTdy/HLpM91MWkin+SYJrDQPiWPOwOi8MgRJ8m8xvdvFPE29R2TLg MiUrpbCJ1EC7CzRgGmfxCsLmW; Received: from 71-211-154-204.hlrn.qwest.net ([71.211.154.204]:34468 helo=prentzel) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nfSUu-002pwY-7R; Fri, 15 Apr 2022 14:24:52 -0600 From: Tom Tromey To: Andreas Arnez Cc: "Rohr, Stephan via Gdb" , "Rohr, Stephan" , "Tom Tromey" Subject: Re: Issue in dwarf2/expr.c References: <877d7reps0.fsf@li-07e5db4c-3052-11b2-a85c-815382633c95.ibm.com> X-Attribution: Tom Date: Fri, 15 Apr 2022 14:24:51 -0600 In-Reply-To: <877d7reps0.fsf@li-07e5db4c-3052-11b2-a85c-815382633c95.ibm.com> (Andreas Arnez's message of "Thu, 14 Apr 2022 15:51:59 +0200") Message-ID: <875ynajdrg.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.154.204 X-Source-L: No X-Exim-ID: 1nfSUu-002pwY-7R X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 71-211-154-204.hlrn.qwest.net (prentzel) [71.211.154.204]:34468 X-Source-Auth: tom+tromey.com X-Email-Count: 3 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3023.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2022 20:24:55 -0000 >> I came across a bug in dwarf2/expr.c:177 in function rw_pieced_value. when reading a pieced value described by DW_OP_piece or DW_OP_bit_piece. >> >> if (value_type (v) != value_enclosing_type (v)) >> internal_error (__FILE__, __LINE__, >> _("Should not be able to create a lazy value with " >> "an enclosing type")); > Since I did some work on this function in the past, I just looked where > this check comes from, and it turns out that it was introduced in 2010 > by Tom Tromey with commit afd74c5ff76010405caddd2834be4a0178fa93dd -- > gdb > * dwarf2loc.c (read_pieced_value): Work properly when 'v' has an > offset. > (write_pieced_value): Likewise. > Perhaps Tom still remembers the rationale? I don't remember, sorry. It's possible I assumed that it should be impossible to create a value with an enclosing type without un-lazying it. Removing the assertion seems fine but it's important to make sure the result works correctly. An enclosing type normally means that the data representing the 'type' is at some offset in the contents, but it seems to me that rw_pieced_value may not handle this case. Tom