From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19926 invoked by alias); 1 Nov 2018 12:32:15 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 19909 invoked by uid 89); 1 Nov 2018 12:32:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.1 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.6 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=H*F:U*mail, excuse X-Spam-Status: No, score=-26.6 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: dd17628.kasserver.com Received: from dd17628.kasserver.com (HELO dd17628.kasserver.com) (85.13.138.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Nov 2018 12:32:09 +0000 Received: from agathebauer.localnet (p5B3A0314.dip0.t-ipconnect.de [91.58.3.20]) by dd17628.kasserver.com (Postfix) with ESMTPSA id 3299462822A4; Thu, 1 Nov 2018 13:32:07 +0100 (CET) From: Milian Wolff To: elfutils-devel@sourceware.org Cc: mark@klomp.org Subject: Re: [PATCH] Fix CFI interpretation for locations on DW_CFA_*_loc boundaries Date: Thu, 01 Nov 2018 12:32:00 -0000 Message-ID: <2508623.ELjUxCkQcu@agathebauer> In-Reply-To: <1857278.YmUYHDWrPl@agathebauer> References: <20181101084818.16153-1-milian.wolff@kdab.com> <1857278.YmUYHDWrPl@agathebauer> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2425884.xhfYVB0e9e"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2018-q4/txt/msg00092.txt.bz2 --nextPart2425884.xhfYVB0e9e Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Content-length: 1781 On Donnerstag, 1. November 2018 10:12:41 CET Milian Wolff wrote: > Please ignore this patch for now - I only looked at one specific case whe= re > this changed the behavior to be in line with libunwind. Sadly, it breaks > other previously working situations. I need to look at this in more detai= l. Yep, that patch is indeed utterly broken - please ignore it and excuse the= =20 noise. I was apparently very confused by the different access patterns in libunwin= d=20 vs. elfutils. Elfutils is validating every location referenced in the FDE (= cf.=20 frame_unwind.c:501). Libunwind on the other hand doesn't do this - it only= =20 accesses the memory to read the location referenced by the return address=20 register. Cheers > On Donnerstag, 1. November 2018 09:48:18 CET Milian Wolff wrote: > > According to the DWARF v3 standard =A76.4.3 3., all call frame > > instructions up to L1 <=3D L2 should be interpreted for an FDE. > > Elfutils currently only interprets L1 < L2, potentially missing > > some instructions when L1 directly points at a DW_CFA_*_loc boundary. > >=20 > > This patch changes the behavior and makes elfutils behave like > > libunwind in that regard. > > --- > >=20 > > libdw/cfi.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > >=20 > > diff --git a/libdw/cfi.c b/libdw/cfi.c > > index 341e055b..332c6b8b 100644 > > --- a/libdw/cfi.c > > +++ b/libdw/cfi.c > > @@ -125,7 +125,7 @@ execute_cfi (Dwarf_CFI *cache, > >=20 > > fs->regs[regno].value =3D (r_value); \ > >=20=20=20=20 > > } while (0) > >=20 > > - while (program < end) > > + while (program <=3D end) > >=20 > > { > >=20=20=20=20=20=20 > > uint8_t opcode =3D *program++; > > Dwarf_Word regno; --=20 Milian Wolff mail@milianw.de http://milianw.de= --nextPart2425884.xhfYVB0e9e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEezawi1aUvUGg3A1+8zYW/HGdOX8FAlva8kIACgkQ8zYW/HGd OX8K3Q/8Cc8H3RKscEsjNzO4HILhVPg68YUjbZCIlLDt4IjqwE2KLJ9IRsD3MMEL +qORSA6rb58RrN3t3TRk/iKLAKbmTFi/12PWwen9V0GB8mv++Q7o16D0h8mR+/g6 CreDnXoyS+aSARNZ9cLbdrS004/bN0YFk56Q9ajxM37q36Q5IpJNFK9hYBm5KJaO +JUaKqYft1u21TA6vIKc9r6zjrBiQQMf6kLGCQnXV9Xt5Z3HPzAdNhH8WTMFh6k6 BVryM6Iho2UVjGx7U1cnD1xwGSVMMfxbntE6lxiS99KxkGjYe7TIjEtjz4hKZsMB v2bNCqJQg5w7ng4nKoYx6ERk2TW6mM1hhf3RR7hb4AOYZjQFNW4fYL75cXFQs0mi qbdvq4hgdAzKDy7tN0x1715SENHXgTYjN3TnjVP7lQ5qXp8anVR4E8uLy1XJiGXa XonY1KK0wtA2NJoZn2puXsf1M3Vfd3b5hqhS23Z4+3JqkGttUmh7ayJF9k2vrfJC BmgNLOZXBsi3ZrKo+Odm1nG1DG+oi/NmPg+gZ7OmB9afskL4EB4MN3niFvQA/Y0C pCLbElvoGe7lGBLDKyGEmyV7D6CMf7BGWJPqxjt0PDzVg+aWVQ8xbzPhljcnaoRp UZVqb/2Y9L1qRSt6nLRcmUdlOrzVz//D6uHWTaLYoR8e3aAUrI8= =Voxz -----END PGP SIGNATURE----- --nextPart2425884.xhfYVB0e9e--