From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 530 invoked by alias); 8 Nov 2017 16:58:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 343 invoked by uid 89); 8 Nov 2017 16:58:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*M:lan, H*M:pinnacle X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Nov 2017 16:58:53 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7D2E8356C6; Wed, 8 Nov 2017 16:58:52 +0000 (UTC) Received: from pinnacle.lan (ovpn-117-42.phx2.redhat.com [10.3.117.42]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 00051600D2; Wed, 8 Nov 2017 16:58:51 +0000 (UTC) Date: Wed, 08 Nov 2017 16:58:00 -0000 From: Kevin Buettner To: Nikola Prica Cc: gdb-patches@sourceware.org, "Ananthakrishna Sowda (asowda)" , "Ivan Baev (ibaev)" , 'Nemanja Popov' , Djordje Todorovic Subject: Re: [PING]Fix for prologue processing on PowerPC Message-ID: <20171108095850.394a48ca@pinnacle.lan> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00183.txt.bz2 See: https://sourceware.org/ml/gdb-patches/2017-10/msg00098.html Kevin On Thu, 26 Oct 2017 12:02:19 +0200 Nikola Prica wrote: > Can someone please take a look into this? >=20 > Thanks, >=20 > Nikola Prica >=20 > On 22.09.2017. 14:11, Nikola Prica wrote: > > After analyzing dump of ppc program, whose crash occurred after=20 > > watchdog_force_here () function, GDB couldn't print full back trace=20 > > because GDB couldn't unwind PC from the watchdog fucntion. > >=20 > > The problem is introduced with the following patch: > >=20 > > https://sourceware.org/ml/gdb-patches/2008-08/msg00245.html > >=20 > > In function skip_prologue(), shifted lr_reg makes below condition alway= s=20 > > false because non-shifted lr_reg value is expected to be checked. > >=20 > > =C2=A0=C2=A0 else if (lr_reg >=3D 0 && > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* std Rx, NUM(r1) || stdu = Rx, NUM(r1) */ > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (((op & 0xffff0000) =3D=3D = (lr_reg | 0xf8010000)) || > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* stw Rx, NUM(r1) */ > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ((op & 0xffff0000) =3D=3D (= lr_reg | 0x90010000)) || > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* stwu Rx, NUM(r1) */ > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ((op & 0xffff0000) =3D=3D (= lr_reg | 0x94010000)))) > >=20 > > Before this fix unwinding was able to work because it relied on unwind > > directives or on some of the next frames to find PC. Problem came with > > watchdog_force_here() function which didn't contain unwind directives. > >=20 > > I wasn't able to produce test case that would show improvements for end > > user. I suppose that changes would be visible if watchdog event was=20 > > called, but I don't have valid ppc board to try this. I have tried this= =20 > > code on simple test case with few functions in back trace. The back=20 > > trace is printed correctly with and without this fix, but the differenc= e=20 > > between those two runs is that the body of the upper condition was=20 > > visited with this patch. After visiting the body there was no need to=20 > > look for PC counter in next frames nor to use unwind directives.=20=20