From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id CHgtJCg7AGMkDyoAWB0awg (envelope-from ) for ; Fri, 19 Aug 2022 21:38:48 -0400 Received: by simark.ca (Postfix, from userid 112) id 7C7BC1E4A7; Fri, 19 Aug 2022 21:38:48 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 643B61E222 for ; Fri, 19 Aug 2022 21:38:47 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 183573858287 for ; Sat, 20 Aug 2022 01:38:44 +0000 (GMT) Received: from mail.voxelsoft.com (45-56-90-239.ip.linodeusercontent.com [45.56.90.239]) by sourceware.org (Postfix) with ESMTPS id 5F9EC3858D39 for ; Sat, 20 Aug 2022 01:38:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5F9EC3858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=voxelsoft.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=voxelsoft.com Received: by mail.voxelsoft.com (Postfix, from userid 65534) id 753D81B3D9; Fri, 19 Aug 2022 21:38:27 -0400 (EDT) Received: from [192.168.1.196] (unknown [95.148.75.49]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.voxelsoft.com (Postfix) with ESMTPS id F3BE01B362; Fri, 19 Aug 2022 21:38:25 -0400 (EDT) Message-ID: Subject: Re: [PATCH] dwarf2: Fix dwarf stack fetch array view size mismatch From: Denis Lukianov To: gdb-patches@sourceware.org, Simon Marchi Date: Sat, 20 Aug 2022 02:38:24 +0100 In-Reply-To: References: <36c80f43b57fcfce3b9db6619e75366db360ae9c.camel@voxelsoft.com> <8bfea13a0966a62eca9cd39617918cff04915b34.camel@voxelsoft.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.1-0ubuntu1 MIME-Version: 1.0 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: , Cc: andrew.burgess@embecosm.com Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On Fri, 2022-08-19 at 20:55 -0400, Simon Marchi wrote: >=20 > I don't understand what you are saying.=C2=A0 All I can see is that the > source array_view size will be of the length of subobj_type: we call > slice with length =3D=3D len, where len is `TYPE_LENGTH (subobj_type)`.= =C2=A0 > And > the destination array_view size is also of the length of subobj_type: > retval was allocated as `allocate_value (subobj_type)`, so its > contents > are of the length of subobj_type. >=20 I know nothing about gdb internals, just reading code in the file: copy (value_contents_all (val).slice (subobj_offset, len), value_contents_raw (retval)); We know val is allocated to be the length of subobj_type. We know retval is allocated to be the length of subobj_type. We know len is the length of subobj_type. We know slice only gives a view same size or smaller. So, the source array_view length must be len - subobj_offset. Therefore source array_view size will be of the length of subobj_type and match the destination only in the event that subobj_offset happens to be zero. The line above does not guarantee it: subobj_offset +=3D n - max; So it looks broken for big endian systems. And maybe any subtype that is not the first element of a type on the others.