Message ID | 20221128052904.36217-1-gaofei@eswincomputing.com |
---|---|
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CA302385454C for <patchwork@sourceware.org>; Mon, 28 Nov 2022 05:29:43 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from azure-sdnproxy.icoremail.net (azure-sdnproxy.icoremail.net [20.232.28.96]) by sourceware.org (Postfix) with SMTP id 5CA16385B181 for <gcc-patches@gcc.gnu.org>; Mon, 28 Nov 2022 05:29:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5CA16385B181 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=eswincomputing.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=eswincomputing.com Received: from localhost.localdomain (unknown [10.12.130.31]) by app2 (Coremail) with SMTP id EggMCgDXtS8iR4RjisETAA--.65016S4; Mon, 28 Nov 2022 13:29:06 +0800 (CST) From: Fei Gao <gaofei@eswincomputing.com> To: gcc-patches@gcc.gnu.org Cc: kito.cheng@gmail.com, palmer@dabbelt.com, Fei Gao <gaofei@eswincomputing.com> Subject: [PATCH 0/1] RISC-V: fix stack access before allocation. Date: Mon, 28 Nov 2022 05:29:03 +0000 Message-Id: <20221128052904.36217-1-gaofei@eswincomputing.com> X-Mailer: git-send-email 2.17.1 X-CM-TRANSID: EggMCgDXtS8iR4RjisETAA--.65016S4 X-Coremail-Antispam: 1UD129KBjvJXoW7ZrWDKryfXr1rtF13XFykAFb_yoW8Gw48pa yfG3Z5trs8Xa47KrnxXFyUJFyrCws3Kry5C347Aw1a9rZ5AFW2qFsrtr43ZrW3GFW8W3WY 9F13uwnruw4UZ3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkI14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4U JVWxJr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gc CE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E 2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJV W8JwACjcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lc2xSY4AK6svPMxAI w28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr 4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxG rwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJw CI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2 z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7VUbWCJPUUUUU== X-CM-SenderInfo: xjdrwv3l6h245lqf0zpsxwx03jof0z/ X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
RISC-V: fix stack access before allocation.
|
|
Message
Fei Gao
Nov. 28, 2022, 5:29 a.m. UTC
In current riscv stack frame allocation, 2 steps are used. The first step allocates memories at least for callee saved GPRs and FPRs, and the second step allocates the rest if stack size is greater than signed 12-bit range. But it's observed in some cases, like gcc.target/riscv/stack_frame.c in my patch, callee saved FPRs fail to be included in the first step allocation, so we get generated instructions like this: li t0,-16384 addi sp,sp,-48 addi t0,t0,752 ... fsw fs4,-4(sp) #issue here of accessing before allocation ... add sp,sp,t0 "fsw fs4,-4(sp)" has issue here of accessing stack before allocation. Although "add sp,sp,t0" reserves later the memory for fs4, it exposes a risk when an interrupt comes in between "fsw fs4,-4(sp)" and "add sp,sp,t0", resulting in a corruption in the stack storing fs4 after interrupt context saving and a failure to get the correct value of fs4 later. This patch fixes issue above, adapts testcases identified in regression tests, and add a new testcase for the change. Fei Gao (1): RISC-V: fix stack access before allocation. gcc/config/riscv/riscv.cc | 2 +- gcc/testsuite/gcc.target/riscv/pr93304.c | 2 +- .../gcc.target/riscv/rvv/base/spill-11.c | 3 +-- gcc/testsuite/gcc.target/riscv/stack_frame.c | 26 +++++++++++++++++++ 4 files changed, 29 insertions(+), 4 deletions(-) create mode 100644 gcc/testsuite/gcc.target/riscv/stack_frame.c