From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) by sourceware.org (Postfix) with ESMTPS id 29E003858C2C for ; Thu, 14 Dec 2023 21:28:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 29E003858C2C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 29E003858C2C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::52e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702589324; cv=none; b=JbzqclsmsvMowRBA1+vZve7o1TROzGt3tvfIk9N9EQz/ThLlxkPL+CK/K8Qeq1C8pe26EEpDD0DdSiqQbzbdtM9yixKw+rZwt8qp2GEfCG74DNLxv19lmhSXv9zkGnCRUfyvdc06HOsJVxb1qNYlvugdlkt08AqFaOttZa5MQsQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702589324; c=relaxed/simple; bh=vuBk0siOunvGoWyUwOtFd507zlIlQDN7S2NpsVK0+ts=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=AiofzNipEjpW7kBjl/NI2RvE4G23nzT0cCVvh4KdE2jE0xzWdC+6l8BITHMJBXYYwjItyypYslVcycKBY6H2bAoZx3254toS1nu3Yr7idAjYtCAsKp6wZ2FWHbo/cn1prxprI8z26O0NrNxvOWUFNrurXQ2wlRAlmRFWposwt5c= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-5c701bd98f3so35053a12.1 for ; Thu, 14 Dec 2023 13:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1702589322; x=1703194122; darn=gcc.gnu.org; h=mime-version:user-agent:message-id:in-reply-to:date:references :organization:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=JfOMdZkveom3dpPw5atfBAGxaPJBLOoennVUbSB4XUA=; b=i1S/eEhy0SWpbzhEFTG8zEsDxa3FIHsnnebqX3nauRiwSfn2Wou/Lo+Ghv8BHVO/pZ omrr0RmX7oIpF79kj3ypTWoopEVBWjrIHaqdNvFYj4cigMQpQqe4S2J+c4WxhK+u5hhK orJ7m/tfLY6olzYVHz3wukwqxXQeilwdUZQfZUC48m5UzfLwc9gs0HoE0zZldwmLhgRh kUYPl4klrksqn0pp1s/hFUQYTCOLaBvcrcIESNS1+UfjUadSA+BMj9++yV8bToW/VDp6 BIIVem1+uyu4bS+8oc2qCNtmQFfegASZpd64yrWIgsBgBsUon4GaABoQeY2RwAkwm/Tf qx3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702589322; x=1703194122; h=mime-version:user-agent:message-id:in-reply-to:date:references :organization:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JfOMdZkveom3dpPw5atfBAGxaPJBLOoennVUbSB4XUA=; b=pWv+KgHK/MD0l7fn8r4qY0WwsRpncmTe5f9KMTqebq4w65Bex3iFBTyNUe1ex4omrC LaC2+2ByzvUVRxsgTaJBWoelqT5SrTHHhParumgZFDh4lqwjlhHTT9uvNqz6BF1FDtDz lUWSo+/6XMLppPaDd+no7BeplUOpCuxAgLevhUlFcy8Um3j05j37JEtqH1nU9yewnmAn aceOkyH0DGjOX3MtO1vmCe4uuVSvoCc7W2bTlZFKXhlyAR0V1nqlVo6/WJh9Imni0SjA +JSFY12eG3/FHl84RNR3qaWCNvN6rseW3lg6ApKiHkLFuAasQ9w4YtGVa+UMpAWvroRx n0tg== X-Gm-Message-State: AOJu0YzXi397G9drVCBkN+QgPhGxJSjqTvvh0g2J3O3rQiljr3WysQtM XvgFpsiRyjZgw8mrUyGX4zBUTc/etVzTfZiLqhDhxw== X-Google-Smtp-Source: AGHT+IGV/g2+9gisgC1Dk/1fSP9y6ZZZz8BOoIQSoPA6bBMMei8xkoTXf25pZbGahsLgW7drMSSLsA== X-Received: by 2002:a05:6a20:daa0:b0:190:37f5:f7da with SMTP id iy32-20020a056a20daa000b0019037f5f7damr6247847pzb.59.1702589321779; Thu, 14 Dec 2023 13:28:41 -0800 (PST) Received: from free.home ([2804:7f1:2080:cecc:5977:530e:86b5:e7be]) by smtp.gmail.com with ESMTPSA id p25-20020a056a0026d900b006ce3b01cba2sm11380636pfw.108.2023.12.14.13.28.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Dec 2023 13:28:41 -0800 (PST) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 3BELSR5u491427 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 14 Dec 2023 18:28:27 -0300 From: Alexandre Oliva To: gcc-patches@gcc.gnu.org Cc: Rainer Orth , Jakub Jelinek , "David S. Miller" , Eric Botcazou Subject: [PATCH #2/2] strub: sparc64: unbias the stack address [PR112917] Organization: Free thinker, does not speak for AdaCore References: Date: Thu, 14 Dec 2023 18:28:27 -0300 In-Reply-To: (Alexandre Oliva's message of "Thu, 14 Dec 2023 17:17:09 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_QUOTING 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: The stack pointer is biased by 2047 bytes on sparc64, so the range it delimits is way off. Unbias the addresses returned by __builtin_stack_address (), so that the strub builtins, inlined or not, can function correctly. I've considered introducing a new target macro, but using STACK_POINTER_OFFSET seems safe, and it enables the register save areas to be scrubbed as well. Because of the large fixed-size outgoing args area next to the register save area on sparc, we still need __strub_leave to not allocate its own frame, otherwise it won't be able to clear part of the frame it should. Regstrapped on x86_64-linux-gnu, also testing on sparc-solaris2.11.3. Ok to install? for gcc/ChangeLog PR middle-end/112917 * builtins.cc (expand_bultin_stack_address): Add STACK_POINTER_OFFSET. --- gcc/builtins.cc | 34 ++++++++++++++++++++++++++++++++-- 1 file changed, 32 insertions(+), 2 deletions(-) diff --git a/gcc/builtins.cc b/gcc/builtins.cc index 7c2732ab79e6f..4c8c514fe8618 100644 --- a/gcc/builtins.cc +++ b/gcc/builtins.cc @@ -5443,8 +5443,38 @@ expand_builtin_frame_address (tree fndecl, tree exp) static rtx expand_builtin_stack_address () { - return convert_to_mode (ptr_mode, copy_to_reg (stack_pointer_rtx), - STACK_UNSIGNED); + rtx ret = convert_to_mode (ptr_mode, copy_to_reg (stack_pointer_rtx), + STACK_UNSIGNED); + + /* Unbias the stack pointer, bringing it to the boundary between the + stack area claimed by the active function calling this builtin, + and stack ranges that could get clobbered if it called another + function. It should NOT encompass any stack red zone, that is + used in leaf functions. + + On SPARC, the register save area is *not* considered active or + used by the active function, but rather as akin to the area in + which call-preserved registers are saved by callees. This + enables __strub_leave to clear what would otherwise overlap with + its own register save area. + + If the address is computed too high or too low, parts of a stack + range that should be scrubbed may be left unscrubbed, scrubbing + may corrupt active portions of the stack frame, and stack ranges + may be doubly-scrubbed by caller and callee. + + In order for it to be just right, the area delimited by + @code{__builtin_stack_address} and @code{__builtin_frame_address + (0)} should encompass caller's registers saved by the function, + local on-stack variables and @code{alloca} stack areas. + Accumulated outgoing on-stack arguments, preallocated as part of + a function's own prologue, are to be regarded as part of the + (caller) function's active area as well, whereas those pushed or + allocated temporarily for a call are regarded as part of the + callee's stack range, rather than the caller's. */ + ret = plus_constant (ptr_mode, ret, STACK_POINTER_OFFSET); + + return force_reg (ptr_mode, ret); } /* Expand a call to builtin function __builtin_strub_enter. */ -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive