From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id B0907385842D for ; Fri, 15 Dec 2023 07:26:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B0907385842D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B0907385842D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::236 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702625184; cv=none; b=QIaKCBJRIRDlpHJRYUyico5n6L0fb7e6CkASxMkhQlJEazlknsHjYhH1Efn2PZwa4L8F6fdUPvMliMDV70qpe4XGDlKiOhBMAAdP/Qq0raWGYX0QO8N9Zuv7W8XqbHoKu8rwLdBeJ/us4/fh2+JzCfIcXaxfpRkeEEr7kxPU46E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702625184; c=relaxed/simple; bh=ZATI1y9uIQ/MgTSCv0zThMDuz2d6islspwl20TILxIg=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=ThkrX4y6otcgi6IrvRrxn8Vz1Tslldy4s7sugEOedPuHeuPcVZsER+VcWa9FWZUUSZYa9PNu/3qK5TmzbB3TPHLKeomVIvlaBMgj2SPl5nzJVQjHKR3iBAIRSoj/MFjiLNu20B3luwARF2zY1n2d9jbFnBgx5l1QfhYfYTiACm8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2cb21afa6c1so4267531fa.0 for ; Thu, 14 Dec 2023 23:26:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702625181; x=1703229981; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=SWZBVFuQ6MC3Wt6CPfJgjnNzMpFWx3nk9VlzxeuAYiQ=; b=VefsTOGBGtJtptxPfvBcnHMewoVvg11KrNCDJbjFNH91oiGnADwWhiTdb0y+Yc9hnn jxC4HzXNvumed/l4Nuow0UyKLcvbAD+gh2Gw1EYdlNtvfKF903czpaM7JuieL5WBbdnb Lt/7Ej+tKqOBRkA5O2Qn6wORgwcmrL3faOjYXQZGwsVrODIo7CNAMbffGdv58CMRvF9G 0CUwPa1mdSDJWgXXJ19gCXbAOwU1NkQauVF2HpWTfdMJXHdTxLPfvtLF2O0mmfUaBkpg AWpgY7RySRD9cZ/eBlL0jkiwKQyN0fBYddP1kIqQ0DyjPHplRrAJ1ZFm+g3QvesTTCgf nMzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702625181; x=1703229981; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SWZBVFuQ6MC3Wt6CPfJgjnNzMpFWx3nk9VlzxeuAYiQ=; b=ayqT/QcdgLYl61ejzAqGjRhfiR6e3vbgeHz7s/GyuLcnQafaQbBtHl4kqqcNJW/v89 G5qZYJzvc83rvZ26MmwAiJfqedZlSQiQi1s9nAgDS3L9yvqw8EQtuazD2p5RtcGs69bg 8Vf7Fk1JuLwem6AgowJXRmX6ulr/ReqBDQC+zjb1dShE8GbSswK2u3FfEvotMKPt786q FJVO1q0im/hPx9/N+mSSFP5ryO4/U4Uuqnkv1Y5ETVmXo6SMK7TtkuPnKv3vzXmoY6rv 6EIeqLq+BgWhWAJFbCSMdYyI680U3FLG/qPapWWu6Gj2I+SSSn9n2EJnXtXIR9lbtlcv Spiw== X-Gm-Message-State: AOJu0Yw+x0NUFdlj+tSV8qdI9i9o0mK36enkg2rX1bxn2v/ccd47bagd IU/lXFLvGB+FgQ+OXUybKG2I6EB7rs33epv4hY4= X-Google-Smtp-Source: AGHT+IGpoKLZ8hA0uJajL5deIYQ2+en2dKRdSLojigcrvHGNsyAiaKoviVHqYSzdBcbzHsaJLsn4LJVPqLI18Jh5SpA= X-Received: by 2002:a19:ee07:0:b0:50e:174c:377a with SMTP id g7-20020a19ee07000000b0050e174c377amr1270393lfb.110.1702625180866; Thu, 14 Dec 2023 23:26:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Fri, 15 Dec 2023 08:26:08 +0100 Message-ID: Subject: Re: [PATCH #2/2] strub: sparc64: unbias the stack address [PR112917] To: Alexandre Oliva Cc: gcc-patches@gcc.gnu.org, Rainer Orth , Jakub Jelinek , "David S. Miller" , Eric Botcazou Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: On Thu, Dec 14, 2023 at 10:29=E2=80=AFPM Alexandre Oliva wrote: > > > 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? It might be worth amending the documentation in case this is unexpected to users? > > > 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 ex= p) > static rtx > expand_builtin_stack_address () > { > - return convert_to_mode (ptr_mode, copy_to_reg (stack_pointer_rtx), > - STACK_UNSIGNED); > + rtx ret =3D 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 =3D 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