From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.voxelsoft.com (45-56-90-239.ip.linodeusercontent.com [45.56.90.239]) by sourceware.org (Postfix) with ESMTPS id 12BEC3858D39 for ; Sat, 20 Aug 2022 01:55:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 12BEC3858D39 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 4A5FA1B3D9; Fri, 19 Aug 2022 21:55:40 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-Spam-Level: X-Spam-Status: No, score=4.6 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KHOP_HELO_FCRDNS, RCVD_IN_BARRACUDACENTRAL, RDNS_DYNAMIC, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 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)) (No client certificate requested) by mail.voxelsoft.com (Postfix) with ESMTPS id B8F521B362; Fri, 19 Aug 2022 21:55:38 -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 Cc: andrew.burgess@embecosm.com Date: Sat, 20 Aug 2022 02:55:37 +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-Spam-Level: **** 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: Sat, 20 Aug 2022 01:56:16 -0000 On Sat, 2022-08-20 at 02:38 +0100, Denis Lukianov wrote: >=20 > I know nothing about gdb internals, just reading code in the file: >=20 > copy (value_contents_all (val).slice (subobj_offset, len), > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value_contents_raw (retval)); >=20 > 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. >=20 > So, the source array_view length must be len - subobj_offset. >=20 > 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: >=20 > subobj_offset +=3D n - max; >=20 > So it looks broken for big endian systems. And maybe any subtype that > is not the first element of a type on the others. >=20 My bad, val is allocated to be length of type. So I'm wrong about all this and the code is fine :)