public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: "Kewen.Lin" <linkw@linux.ibm.com>
Cc: David Edelsohn <dje.gcc@gmail.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	Richard Biener <richard.guenther@gmail.com>,
	Jakub Jelinek <jakub@redhat.com>,
	Peter Bergner <bergner@linux.ibm.com>,
	Segher Boessenkool <segher@kernel.crashing.org>,
	Jeff Law <jeffreyalaw@gmail.com>,
	Richard Sandiford <richard.sandiford@arm.com>
Subject: Re: [PATCH] strub: Only unbias stack point for SPARC_STACK_BOUNDARY_HACK [PR113100]
Date: Fri, 19 Jan 2024 03:23:32 -0300	[thread overview]
Message-ID: <or34utq1sr.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <ee30c077-4217-abcb-638d-492c69ec3b58@linux.ibm.com> (Kewen Lin's message of "Thu, 18 Jan 2024 14:28:17 +0800")

On Jan 18, 2024, "Kewen.Lin" <linkw@linux.ibm.com> wrote:

> Not sure if I missed something in the testing, could you
> kindly double check if those test cases started to fail from r14-6275 on your
> env?

My guess is that they started to fail when David attempted to bypass the
strub tests by changing the dg proc that detects strub support.  The
tests then detected the mismatch between the result of the proc and the
expected errors when strub is disabled properly.


Here's the cleanup patch I promised.  Sorry it took so long, I was
hitting bootstrap errors even on a pristine tree yesterday.

Regstrapped on x86_64-linux-gnu.  This patch restores the status on
sparc-sun-solaris from before Kewen's patch, while leaving all other
ports unchanged.  Ok to install?


strub: introduce STACK_ADDRESS_OFFSET

Since STACK_POINTER_OFFSET is not necessarily at the boundary between
caller- and callee-owned stack, as desired by
__builtin_stack_address(), and using it as if it were or not causes
problems, introduce a new macro so that ports can define it suitably,
without modifying STACK_POINTER_OFFSET.


for  gcc/ChangeLog

	PR middle-end/112917
	PR middle-end/113100
	* builtins.cc (expand_builtin_stack_address): Use
	STACK_ADDRESS_OFFSET.
	* doc/extend.texi (__builtin_stack_address): Adjust.
	* config/sparc/sparc.h (STACK_ADDRESS_OFFSET): Define.
	* doc/tm.texi.in (STACK_ADDRESS_OFFSET): Document.
	* doc/tm.texi.in: Rebuilt.
---
 gcc/builtins.cc          |    5 ++---
 gcc/config/sparc/sparc.h |    7 +++++++
 gcc/doc/extend.texi      |    2 +-
 gcc/doc/tm.texi          |   29 +++++++++++++++++++++++++++++
 gcc/doc/tm.texi.in       |   29 +++++++++++++++++++++++++++++
 5 files changed, 68 insertions(+), 4 deletions(-)

diff --git a/gcc/builtins.cc b/gcc/builtins.cc
index 09f2354f1144b..37df7dcda0a0e 100644
--- a/gcc/builtins.cc
+++ b/gcc/builtins.cc
@@ -5450,7 +5450,7 @@ expand_builtin_stack_address ()
   rtx ret = convert_to_mode (ptr_mode, copy_to_reg (stack_pointer_rtx),
 			     STACK_UNSIGNED);
 
-#ifdef SPARC_STACK_BOUNDARY_HACK
+#ifdef STACK_ADDRESS_OFFSET
   /* 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
@@ -5477,8 +5477,7 @@ expand_builtin_stack_address ()
      (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.  */
-  if (SPARC_STACK_BOUNDARY_HACK)
-    ret = plus_constant (ptr_mode, ret, STACK_POINTER_OFFSET);
+  ret = plus_constant (ptr_mode, ret, STACK_ADDRESS_OFFSET);
 #endif
 
   return force_reg (ptr_mode, ret);
diff --git a/gcc/config/sparc/sparc.h b/gcc/config/sparc/sparc.h
index fc064a92c22d9..fb074808d30d4 100644
--- a/gcc/config/sparc/sparc.h
+++ b/gcc/config/sparc/sparc.h
@@ -734,6 +734,13 @@ along with GCC; see the file COPYING3.  If not see
      parameter regs.  */
 #define STACK_POINTER_OFFSET (FIRST_PARM_OFFSET(0) + SPARC_STACK_BIAS)
 
+/* Unbias the stack pointer if needed, and move past the register save area,
+   that is never in use while a function is active, so that it is regarded as a
+   callee save area rather than as part of the function's own stack area.  This
+   enables __strub_leave() to do a better job of clearing the stack frame of a
+   previously-called sibling.  */
+#define STACK_ADDRESS_OFFSET STACK_POINTER_OFFSET
+
 /* Base register for access to local variables of the function.  */
 #define HARD_FRAME_POINTER_REGNUM 30
 
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 0bc586d120e76..00d8aa390cc5e 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -12791,7 +12791,7 @@ situations.
 
 @deftypefn {Built-in Function} {void *} __builtin_stack_address ()
 This function returns the stack pointer register, offset by
-@code{STACK_POINTER_OFFSET}.
+@code{STACK_ADDRESS_OFFSET} if that's defined.
 
 Conceptually, the returned address returned by this built-in function is
 the boundary between the stack area allocated for use by its caller, and
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 69ae63c77de6e..c8b8b126b2424 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -3456,6 +3456,35 @@ or type, otherwise return false.  The default implementation always returns
 true.
 @end deftypefn
 
+@defmac STACK_ADDRESS_OFFSET
+Offset from the stack pointer register to the boundary address between
+the stack area claimed by an active function, 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.
+
+This value is added to the stack pointer register to compute the address
+returned by @code{__builtin_stack_address}, and this is its only use.
+If this macro is not defined, no offset is added.  Defining it like
+@code{STACK_POINTER_OFFSET} may be appropriate for many machines, but
+not all.
+
+On SPARC, for example, 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, so the stack address is
+above that area, even though the (unbiased) stack pointer points below
+it.  This enables @code{__strub_leave} to clear what would otherwise
+overlap with its own register save area.
+
+On PowerPC, @code{STACK_POINTER_OFFSET} also reserves space for a save
+area, but that area is used by the caller rather than the callee, so the
+boundary address is below it.
+
+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.
+@end defmac
+
 @defmac TARGET_STRUB_USE_DYNAMIC_ARRAY
 If defined to nonzero, @code{__strub_leave} will allocate a dynamic
 array covering the stack range that needs scrubbing before clearing it.
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 21343d4d1bf2f..658e1e63371e5 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -2688,6 +2688,35 @@ may reduce the size of debug information on some ports.
 
 @hook TARGET_HAVE_STRUB_SUPPORT_FOR
 
+@defmac STACK_ADDRESS_OFFSET
+Offset from the stack pointer register to the boundary address between
+the stack area claimed by an active function, 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.
+
+This value is added to the stack pointer register to compute the address
+returned by @code{__builtin_stack_address}, and this is its only use.
+If this macro is not defined, no offset is added.  Defining it like
+@code{STACK_POINTER_OFFSET} may be appropriate for many machines, but
+not all.
+
+On SPARC, for example, 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, so the stack address is
+above that area, even though the (unbiased) stack pointer points below
+it.  This enables @code{__strub_leave} to clear what would otherwise
+overlap with its own register save area.
+
+On PowerPC, @code{STACK_POINTER_OFFSET} also reserves space for a save
+area, but that area is used by the caller rather than the callee, so the
+boundary address is below it.
+
+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.
+@end defmac
+
 @defmac TARGET_STRUB_USE_DYNAMIC_ARRAY
 If defined to nonzero, @code{__strub_leave} will allocate a dynamic
 array covering the stack range that needs scrubbing before clearing it.


-- 
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

  reply	other threads:[~2024-01-19  6:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-08  2:35 Kewen.Lin
2024-01-08 11:44 ` Richard Biener
2024-01-10  5:11   ` Kewen.Lin
2024-01-11  9:05 ` Alexandre Oliva
2024-01-12  3:02   ` Kewen.Lin
2024-01-12 11:03     ` Alexandre Oliva
2024-01-15  6:13       ` Kewen.Lin
2024-01-18  1:06 ` Alexandre Oliva
2024-01-18  1:27   ` David Edelsohn
2024-01-18  6:28     ` Kewen.Lin
2024-01-19  6:23       ` Alexandre Oliva [this message]
2024-01-30  3:35         ` Alexandre Oliva
2024-01-30  7:32           ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=or34utq1sr.fsf@lxoliva.fsfla.org \
    --to=oliva@adacore.com \
    --cc=bergner@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jeffreyalaw@gmail.com \
    --cc=linkw@linux.ibm.com \
    --cc=richard.guenther@gmail.com \
    --cc=richard.sandiford@arm.com \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).