From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24628 invoked by alias); 25 Apr 2017 13:11:23 -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 24600 invoked by uid 89); 25 Apr 2017 13:11:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=lastly, our X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Message-ID: <1493125881.31726.44.camel@klomp.org> Subject: Re: [PATCH 5/5] Add frame pointer unwinding for aarch64 From: Mark Wielaard To: elfutils-devel@sourceware.org Cc: Ulf Hermann Date: Tue, 25 Apr 2017 22:13:00 -0000 In-Reply-To: <1493124579-21017-5-git-send-email-mark@klomp.org> References: <1493124006.31726.33.camel@klomp.org> <1493124579-21017-1-git-send-email-mark@klomp.org> <1493124579-21017-5-git-send-email-mark@klomp.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.12.11 (3.12.11-22.el7) Mime-Version: 1.0 X-SW-Source: 2017-q2/txt/msg00091.txt.bz2 On Tue, 2017-04-25 at 14:49 +0200, Mark Wielaard wrote: > +bool > +EBLHOOK(unwind) (Ebl *ebl __attribute__ ((unused)), Dwarf_Addr pc __attr= ibute__ ((unused)), > + ebl_tid_registers_t *setfunc, ebl_tid_registers_get_t *= getfunc, > + ebl_pid_memory_read_t *readfunc, void *arg, > + bool *signal_framep __attribute__ ((unused))) > +{ > + Dwarf_Word fp, lr, sp; > + > + if (!getfunc(LR_REG, 1, &lr, arg)) > + return false; > + > + if (!getfunc(FP_REG, 1, &fp, arg)) > + fp =3D 0; > + > + if (!getfunc(SP_REG, 1, &sp, arg)) > + sp =3D 0; > + > + Dwarf_Word newPc, newLr, newFp, newSp; > + > + // The initial frame is special. We are expected to return lr directly= in this case, and we'll > + // come back to the same frame again in the next round. > + if ((pc & 0x1) =3D=3D 0) > + { > + newLr =3D lr; > + newFp =3D fp; > + newSp =3D sp; > + } > + else > + { > + if (!readfunc(fp + LR_OFFSET, &newLr, arg)) > + newLr =3D 0; > + > + if (!readfunc(fp + FP_OFFSET, &newFp, arg)) > + newFp =3D 0; > + > + newSp =3D fp + SP_OFFSET; > + } > + > + newPc =3D newLr & (~0x1); > + if (!setfunc(-1, 1, &newPc, arg)) > + return false; My question is about this "initial frame". In our testcase we don't have this case since the backtrace starts in a function that has some CFI. But I assume you have some tests that rely on this behavior. The first question is how/why the (pc & 0x1) =3D=3D 0 check works? Why is that the correct check? Secondly, if it really is the initial (or signal frame) we are after, should we pass in into bool *signal_framep argument. Currently we don't Lastly could you instead of returning the frame itself with just the pc adjusted do that directly? if ((pc & 0x1) =3D=3D 0) lr =3D lr & (~0x1); And then use the code in the else clause always? All the above might simply be me not understanding the significance of the initial frame. Cheers, Mark