From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by sourceware.org (Postfix) with ESMTPS id A88613858414 for ; Mon, 28 Nov 2022 16:57:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A88613858414 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x1029.google.com with SMTP id w15-20020a17090a380f00b0021873113cb4so10758192pjb.0 for ; Mon, 28 Nov 2022 08:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=D8e0EAuQFZLJk41/mgaJ5KWvItlS5omTUAWL1LVkwBw=; b=kb3GBV8MkJdClfx7+sxue3C8ADa2wKvrmi7OotJSOlmrrzXq8wRLEr54JsU7MBt7Mt 4oxuUocquPPStIOll9z+Hk8Jc54kHlhMrQtOtzQydIOXYfAcOBZLVPJ8qZQkBI4jt9i1 HQP9GMxvqf7mEMM3qz0qJFPy5Ooz0BwMX6l7TVn4flCkxQ5fWxbgSFfh60VpcDQFfFBl WyzJizT3M8h7EmI8X5wQVcwhl0wA5yPMz5rVlaimkQ6989rGb1UyZRxVtwksunyLHhmz oH3vamsU2PZV5YcvWsMJ0Dq6xLM6sKqSMmGzBb9nmSpUQHP8HMV5V5N63FdV2kKzXQwe VnCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=D8e0EAuQFZLJk41/mgaJ5KWvItlS5omTUAWL1LVkwBw=; b=T4Uk1MidSFXo3dGEvIbYmPVBuwq9kE1Loz1POnbvHGngIkSy8UuDe2WQyOe5CJ+xUD +IQk0mTJR+e0PxdVMlk90wrlFityxQYSMo8lFmmEruyKn5bkiYwMCmSNH98vFK42ug7J qr1Jyd8Ibv1C6aNUIM252g6hs/nki1ytN/zY4ms9ADjotLaPk+y8VJqb0mdFMiFrjLFV q+8AFSJbORjzk+M0sBudffdxrfLEsu/GUJjd2xaUTkmNf5I9wJB2lnoGPDwrnkQQby0d 12ohcidoB50U76YqRXd+TwO6jluFMWqSxt60DbxS/knNoLOaFsf35kSv4DlUfVQ7a2fX iwxA== X-Gm-Message-State: ANoB5plh/TlwOFDj+F8ml6toEI3haY3zNvoaZV0T9hUq/ZhXmBpj/QjT 4PsYIG7lyMjyrw1dTNbVuzk= X-Google-Smtp-Source: AA0mqf50G4d2I8pXGAuV0TC7j1yK6fY0dPTjVm2JXZVIsxzuJLeQ0vmFtf6yFseiALfrjBXCjKykKQ== X-Received: by 2002:a17:902:d302:b0:189:6077:5595 with SMTP id b2-20020a170902d30200b0018960775595mr20237486plc.84.1669654636601; Mon, 28 Nov 2022 08:57:16 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id x13-20020a170902ec8d00b00189929219acsm1411772plg.183.2022.11.28.08.57.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Nov 2022 08:57:15 -0800 (PST) Message-ID: Date: Mon, 28 Nov 2022 09:57:14 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH 1/1] RISC-V: fix stack access before allocation. Content-Language: en-US To: Fei Gao , gcc-patches@gcc.gnu.org Cc: kito.cheng@gmail.com, palmer@dabbelt.com References: <20221128052829.36087-1-gaofei@eswincomputing.com> <20221128052829.36087-2-gaofei@eswincomputing.com> From: Jeff Law In-Reply-To: <20221128052829.36087-2-gaofei@eswincomputing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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 List-Id: On 11/27/22 22:28, Fei Gao wrote: > 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. > > gcc/ChangeLog: > > * config/riscv/riscv.cc (riscv_first_stack_step): > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/pr93304.c: Adapt testcase for the change, constrain match to assembly instructions only. > * gcc.target/riscv/rvv/base/spill-11.c: Adapt testcase for the change. > * gcc.target/riscv/stack_frame.c: New test. They key here is that the MIN_FIRST_STEP wasn't including the FP save space.  The stack layout diagram before riscv_stack_align, combined with the info you provided made that pretty clear. Good job tracking it down -- these can be tough to reproduce and thus tough to debug/fix. I made minor adjustments to the ChangeLog and committed your change to the trunk. Thanks, Jeff