From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69695 invoked by alias); 14 Jun 2017 18:50:08 -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 69676 invoked by uid 89); 14 Jun 2017 18:50:07 -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=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=Various, calculating, our, site X-Spam-Status: No, score=-0.9 required=5.0 tests=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 Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 Jun 2017 18:50:06 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 2A2E5304D63A; Wed, 14 Jun 2017 20:50:09 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 180644BA318C; Wed, 14 Jun 2017 20:50:09 +0200 (CEST) Message-ID: <1497466208.3755.298.camel@klomp.org> Subject: Re: overflows in Dwfl_Thread_Callbacks::memory_read callback From: Mark Wielaard To: Milian Wolff Cc: elfutils-devel@sourceware.org Date: Thu, 15 Jun 2017 20:37:00 -0000 In-Reply-To: <1553274.yb8VYApAHh@agathebauer> References: <2117244.RMs6e62TRU@agathebauer> <1497362761.3755.222.camel@klomp.org> <1553274.yb8VYApAHh@agathebauer> 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-IsSubscribed: yes X-SW-Source: 2017-q2/txt/msg00251.txt.bz2 On Tue, 2017-06-13 at 18:15 +0200, Milian Wolff wrote: > > I am not following the above trace completely, but what is going on > > seems to be that we have CFI and want to get a register value. So we > > call dwarf_frame_register to determine the DWARF expression operations > > that we need to execute to get the register value. dwarf_frame_register > > determines that that the register is described by a register offset > > value rule, so it generates operations saying see an the CFA > > (DW_OP_call_frame_cfa) plus some offset (DW_OP_plus_uconst) as a value > > (so read the value from cfa + offset, which is somewhere on the stack). > > But then the cfa comes out as 15? That is obviously bogus. But I don't > > really understand how that happened. It should be a value somewhere near > > the current stack. Then reading 15 - offset (16) clearly fails. >=20 > Right, so that cfa value - is that in the DWARF info? So is the dso "brok= en"?=20 > Or is this some runtime value that we returned earlier in our register or= =20 > memory callback implementation? This is how DWARF defines the CFA: An area of memory that is allocated on a stack called a =E2=80=9Cca= ll frame.=E2=80=9D The call frame is identified by an address on the s= tack. We refer to this address as the Canonical Frame Address or CFA. Typically, the CFA is defined to be the value of the stack pointer at the call site in the previous frame (which may be different from its value on entry to the current frame). So in practice it points inside the stack where the previous stack pointer was when this function was called. Various things can often be found as offset of the CFA, the return address, saved register values, arguments to the current function etc. You start unwinding by first calculating the CFA. I cannot immediately see why that went wrong in this case. But either we picked the wrong CFI (Call Frame Information) for the current pc and are just calculating something bogus. Or one of the needed values to calculate the CFA was garbage (either a bad register value or a bad stack value). Cheers, Makr