From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C0B28C433EF for ; Sun, 29 May 2022 15:19:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=y96yZyeVTpcE+tKakYcsg3c88NYtozKSe4iuouzen14=; b=cIMQLsX0b5upS5 iaXtxgcDqL1vU/kJCFo4dMvIqLMDdtzZ3XMAmxOwdQHpB4gGM0GnLc89tIyeCOmL2yZ7ZneSh5o3M neRCEBe6wmanJFJR78p0Lp5RaNhQ23umB8pU9W9HOQOIvu3A7ZepAWOAdl6umKCxzZlgVcIxESxkz M9q3g0Tt/Zl3Ku+Mf3SmrdmwbBHX8O+Ydl7cajVI5yp++aYmOktGgVzvuzH4Cj4ZkAY76TV5a33+Q QY64axbWW0KEXvv6oqhC3oPh5EEBzcyiHPlqhsIg6z4upMHodb9/Q6nipoTjOIK8vY9S575ialdQk 05S6DiQLTp1ocWJhpJhA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nvKgA-004941-Bv; Sun, 29 May 2022 15:18:06 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nvKg6-00493K-QI for linux-arm-kernel@lists.infradead.org; Sun, 29 May 2022 15:18:04 +0000 Received: from [192.168.254.32] (unknown [47.189.24.195]) by linux.microsoft.com (Postfix) with ESMTPSA id 24BF720BA5A0; Sun, 29 May 2022 08:18:01 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 24BF720BA5A0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1653837481; bh=OnqLwBgpiR5JuHmYgm/0FFiPa8iwxGxQscALfoSTbJY=; h=Date:Subject:To:References:From:In-Reply-To:From; b=jiZGA5qvjxvb7hGa09YO+1rAIIB788kBcH1T3L34EEZiLDK4Afx8tvyt1x5Z30aBE knQYm0zWdTpNy8U/J096LrWzW48rZrXeltg8YCZ2SF6KTL9RXlVFNWUXBisz1WOfeI dBTZu2QmkFON1gAAMJmO/yibDlcxS8zBfdJ651lA= Message-ID: Date: Sun, 29 May 2022 10:18:00 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [RFC PATCH v2 11/20] objtool: arm64: Walk instructions and compute CFI for each instruction Content-Language: en-US To: Chen Zhongjin , jpoimboe@redhat.com, peterz@infradead.org, mark.rutland@arm.com, broonie@kernel.org, nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com, catalin.marinas@arm.com, will@kernel.org, jamorris@linux.microsoft.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220524001637.1707472-1-madvenka@linux.microsoft.com> <20220524001637.1707472-12-madvenka@linux.microsoft.com> <767e814c-b3cc-73a1-d283-82dbc0287cde@huawei.com> From: "Madhavan T. Venkataraman" In-Reply-To: <767e814c-b3cc-73a1-d283-82dbc0287cde@huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220529_081802_954118_40FFB6BD X-CRM114-Status: GOOD ( 20.41 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 5/24/22 08:45, Chen Zhongjin wrote: > Hi, > > On 2022/5/24 8:16, madvenka@linux.microsoft.com wrote: >> From: "Madhavan T. Venkataraman" >> >> Implement arch_initial_func_cfi_state() to initialize the CFI for a >> function. >> >> Add code to fpv_decode() to walk the instructions in every function and >> compute the CFI information for each instruction. >> >> Implement special handling for cases like jump tables. >> >> Signed-off-by: Madhavan T. Venkataraman >> --- >> tools/objtool/arch/arm64/decode.c | 15 +++ >> tools/objtool/fpv.c | 204 ++++++++++++++++++++++++++++++ >> 2 files changed, 219 insertions(+) > ... >> +static void update_cfi_state(struct cfi_state *cfi, struct stack_op *op) >> +{ >> + struct cfi_reg *cfa = &cfi->cfa; >> + struct cfi_reg *regs = cfi->regs; >> + >> + if (op->src.reg == CFI_SP) { >> + if (op->dest.reg == CFI_SP) >> + cfa->offset -= op->src.offset; >> + else >> + regs[CFI_FP].offset = -cfa->offset + op->src.offset; > Seems wrong here, we don't have any op->src.offset for [mov x29, sp] so here we > get: fp->offset = -cfa->offset. The dumped info also proves this. See the example below. > >> + case UNWIND_HINT_TYPE_CALL: >> + /* Normal call */ >> + frame->cfa += orc->sp_offset; >> + fp = frame->cfa + orc->fp_offset; >> + break; > Obviously this is not conform to the reliability check because we get > frame->cfa == fp here. > See the example below: > IIUC your sp_offset equals to stack length, and fp_offset is offset from next > x29 to next CFA. So maybe here we should have > regs[CFI_FP].offset = regs[CFI_SP].offset for [mov x29, sp]. > > Anyway, in original objtool sp_offset and fp_offset both represents the offset > from CFA to REGs. I think it's better not spoiling their original meaning and > just extending. > > I am not spoiling anything. Let us take an example: ffff800008010000 : ffff800008010000: d503201f nop ffff800008010004: d503201f nop ffff800008010008: d503233f paciasp ffff80000801000c: a9be7bfd stp x29, x30, [sp, #-32]! ffff800008010010: 910003fd mov x29, sp ffff800008010014: f9000bf3 str x19, [sp, #16] The stack pointer is first moved by -32 and the FP and LR are stored there. At this point, SP is pointing to the frame. The CFA is: CFA = SP + 32 The frame pointer has been stored at the location pointed to by the SP. So, FP should be: FP = CFA - 32 Therefore, at instruction address ffff800008010014: frame->cfa = SP + 32; frame->fp = frame->cfa - 32 = SP; So, if a call/interrupt happens after this instruction, the frame pointer computed from the above data will match with the actual frame pointer. I have verified this using the DWARF data generated by the compiler. It is correct. I have also verified that the stack trace through such code passes the reliability check. That is, it computes the frame pointer correctly which matches with the actual frame pointer. Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel