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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58C98C433EF for ; Sun, 29 May 2022 15:18:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230520AbiE2PSG (ORCPT ); Sun, 29 May 2022 11:18:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57958 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229741AbiE2PSD (ORCPT ); Sun, 29 May 2022 11:18:03 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 60CD2377CB; Sun, 29 May 2022 08:18:02 -0700 (PDT) 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> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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 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