public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH v5 0/2] IBM zSystems: Improve storing asan frame_pc
@ 2022-09-27  0:23 Ilya Leoshkevich
  2022-09-27  0:23 ` [PATCH v5 1/2] asan: specify alignment for LASANPC labels Ilya Leoshkevich
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Ilya Leoshkevich @ 2022-09-27  0:23 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: gcc-patches, Ilya Leoshkevich

Hi,

This is a resend of v4 with slightly adjusted commit messages:

v1: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525016.html
v2: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525069.html
v3: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548338.html
v4: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549252.html

It still survives the bootstrap and the regtest on x86_64-redhat-linux,
s390x-redhat-linux and ppc64le-redhat-linux.  It also fixes [1].

I also tried the approach with moving .LASANPC closer to the function
label and using FUNCTION_BOUNDARY instead of introducing
CODE_LABEL_BOUNDARY, but the problem there is that it's hard to catch
the moment where the function label is written.  Architectures can do
it by calling ASM_OUTPUT_LABEL() or assemble_name() in
ASM_DECLARE_FUNCTION_NAME(), ASM_OUTPUT_FUNCTION_LABEL() or
TARGET_ASM_FUNCTION_PROLOGUE().  epiphany_start_function() does that
twice, but passes the same decl to both calls.  Note that simply
moving asan_function_start() to final_start_function_1() is not enough,
since an architecture can write something after the function label.
This all means that for this approach to work, all the architectures
need to be adjusted, which looks like an overkill to me.

Best regards,
Ilya

[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593666.html


Ilya Leoshkevich (2):
  asan: specify alignment for LASANPC labels
  IBM zSystems: Define CODE_LABEL_BOUNDARY

 gcc/asan.cc                                    |  1 +
 gcc/config/s390/s390.h                         |  3 +++
 gcc/defaults.h                                 |  5 +++++
 gcc/doc/tm.texi                                |  4 ++++
 gcc/doc/tm.texi.in                             |  4 ++++
 gcc/testsuite/gcc.target/s390/asan-no-gotoff.c | 15 +++++++++++++++
 6 files changed, 32 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/s390/asan-no-gotoff.c

-- 
2.37.2


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH v5 1/2] asan: specify alignment for LASANPC labels
  2022-09-27  0:23 [PATCH v5 0/2] IBM zSystems: Improve storing asan frame_pc Ilya Leoshkevich
@ 2022-09-27  0:23 ` Ilya Leoshkevich
  2022-09-27  0:23 ` [PATCH v5 2/2] IBM zSystems: Define CODE_LABEL_BOUNDARY Ilya Leoshkevich
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Ilya Leoshkevich @ 2022-09-27  0:23 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: gcc-patches, Ilya Leoshkevich

gcc/ChangeLog:

2020-06-30  Ilya Leoshkevich  <iii@linux.ibm.com>

	* asan.cc (asan_emit_stack_protection): Use CODE_LABEL_BOUNDARY.
	* defaults.h (CODE_LABEL_BOUNDARY): New macro.
	* doc/tm.texi: Document CODE_LABEL_BOUNDARY.
	* doc/tm.texi.in: Likewise.
---
 gcc/asan.cc        | 1 +
 gcc/defaults.h     | 5 +++++
 gcc/doc/tm.texi    | 4 ++++
 gcc/doc/tm.texi.in | 4 ++++
 4 files changed, 14 insertions(+)

diff --git a/gcc/asan.cc b/gcc/asan.cc
index 8276f12cc69..62f50ee769b 100644
--- a/gcc/asan.cc
+++ b/gcc/asan.cc
@@ -1960,6 +1960,7 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned int alignb,
   DECL_INITIAL (decl) = decl;
   TREE_ASM_WRITTEN (decl) = 1;
   TREE_ASM_WRITTEN (id) = 1;
+  SET_DECL_ALIGN (decl, CODE_LABEL_BOUNDARY);
   emit_move_insn (mem, expand_normal (build_fold_addr_expr (decl)));
   shadow_base = expand_binop (Pmode, lshr_optab, base,
 			      gen_int_shift_amount (Pmode, ASAN_SHADOW_SHIFT),
diff --git a/gcc/defaults.h b/gcc/defaults.h
index 953605c1627..52a471cf08e 100644
--- a/gcc/defaults.h
+++ b/gcc/defaults.h
@@ -1455,4 +1455,9 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 typedef TARGET_UNIT target_unit;
 #endif
 
+/* Alignment required for a code label, in bits.  */
+#ifndef CODE_LABEL_BOUNDARY
+#define CODE_LABEL_BOUNDARY BITS_PER_UNIT
+#endif
+
 #endif  /* ! GCC_DEFAULTS_H */
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 858bfb80cec..cc588ee23b5 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -1075,6 +1075,10 @@ to a value equal to or larger than @code{STACK_BOUNDARY}.
 Alignment required for a function entry point, in bits.
 @end defmac
 
+@defmac CODE_LABEL_BOUNDARY
+Alignment required for a code label, in bits.
+@end defmac
+
 @defmac BIGGEST_ALIGNMENT
 Biggest alignment that any data type can require on this machine, in
 bits.  Note that this is not the biggest alignment that is supported,
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 21b849ea32a..a0b725b0685 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -971,6 +971,10 @@ to a value equal to or larger than @code{STACK_BOUNDARY}.
 Alignment required for a function entry point, in bits.
 @end defmac
 
+@defmac CODE_LABEL_BOUNDARY
+Alignment required for a code label, in bits.
+@end defmac
+
 @defmac BIGGEST_ALIGNMENT
 Biggest alignment that any data type can require on this machine, in
 bits.  Note that this is not the biggest alignment that is supported,
-- 
2.37.2


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH v5 2/2] IBM zSystems: Define CODE_LABEL_BOUNDARY
  2022-09-27  0:23 [PATCH v5 0/2] IBM zSystems: Improve storing asan frame_pc Ilya Leoshkevich
  2022-09-27  0:23 ` [PATCH v5 1/2] asan: specify alignment for LASANPC labels Ilya Leoshkevich
@ 2022-09-27  0:23 ` Ilya Leoshkevich
  2022-10-18  2:28 ` PING [PATCH v5 0/2] IBM zSystems: Improve storing asan frame_pc Ilya Leoshkevich
  2022-10-25 17:37 ` Jakub Jelinek
  3 siblings, 0 replies; 5+ messages in thread
From: Ilya Leoshkevich @ 2022-09-27  0:23 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: gcc-patches, Ilya Leoshkevich

Currently s390 emits the following sequence to store a frame_pc:

        a:
        .LASANPC0:

                lg      %r1,.L5-.L4(%r13)
                la      %r1,0(%r1,%r12)
                stg     %r1,176(%r11)

        .L5:
                .quad   .LASANPC0@GOTOFF

The reason GOT indirection is used instead of larl is that gcc does not
know that .LASANPC0, being a code label, is aligned on a 2-byte
boundary, and larl can load only even addresses.

Define CODE_LABEL_BOUNDARY in order to get rid of GOT indirection:

                larl    %r1,.LASANPC0
                stg     %r1,176(%r11)

gcc/ChangeLog:

2020-06-30  Ilya Leoshkevich  <iii@linux.ibm.com>

        * config/s390/s390.h (CODE_LABEL_BOUNDARY): Specify that s390
        requires code labels to be aligned on a 2-byte boundary.

gcc/testsuite/ChangeLog:

2019-06-30  Ilya Leoshkevich  <iii@linux.ibm.com>

        * gcc.target/s390/asan-no-gotoff.c: New test.
---
 gcc/config/s390/s390.h                         |  3 +++
 gcc/testsuite/gcc.target/s390/asan-no-gotoff.c | 15 +++++++++++++++
 2 files changed, 18 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/s390/asan-no-gotoff.c

diff --git a/gcc/config/s390/s390.h b/gcc/config/s390/s390.h
index be566215df2..7d078ce6868 100644
--- a/gcc/config/s390/s390.h
+++ b/gcc/config/s390/s390.h
@@ -368,6 +368,9 @@ extern const char *s390_host_detect_local_cpu (int argc, const char **argv);
 /* Allocation boundary (in *bits*) for the code of a function.  */
 #define FUNCTION_BOUNDARY 64
 
+/* Alignment required for a code label, in bits.  */
+#define CODE_LABEL_BOUNDARY 16
+
 /* There is no point aligning anything to a rounder boundary than this.  */
 #define BIGGEST_ALIGNMENT 64
 
diff --git a/gcc/testsuite/gcc.target/s390/asan-no-gotoff.c b/gcc/testsuite/gcc.target/s390/asan-no-gotoff.c
new file mode 100644
index 00000000000..f555e4e96f8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/asan-no-gotoff.c
@@ -0,0 +1,15 @@
+/* Test that ASAN labels are referenced without unnecessary indirections.  */
+
+/* { dg-do compile } */
+/* { dg-options "-fPIE -O2 -fsanitize=kernel-address --param asan-stack=1" } */
+
+extern void c (int *);
+
+void a ()
+{
+  int b;
+  c (&b);
+}
+
+/* { dg-final { scan-assembler {\tlarl\t%r\d+,\.LASANPC\d+} } } */
+/* { dg-final { scan-assembler-not {\.LASANPC\d+@GOTOFF} } } */
-- 
2.37.2


^ permalink raw reply	[flat|nested] 5+ messages in thread

* PING [PATCH v5 0/2] IBM zSystems: Improve storing asan frame_pc
  2022-09-27  0:23 [PATCH v5 0/2] IBM zSystems: Improve storing asan frame_pc Ilya Leoshkevich
  2022-09-27  0:23 ` [PATCH v5 1/2] asan: specify alignment for LASANPC labels Ilya Leoshkevich
  2022-09-27  0:23 ` [PATCH v5 2/2] IBM zSystems: Define CODE_LABEL_BOUNDARY Ilya Leoshkevich
@ 2022-10-18  2:28 ` Ilya Leoshkevich
  2022-10-25 17:37 ` Jakub Jelinek
  3 siblings, 0 replies; 5+ messages in thread
From: Ilya Leoshkevich @ 2022-10-18  2:28 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: gcc-patches

On Tue, 2022-09-27 at 02:23 +0200, Ilya Leoshkevich wrote:
> Hi,
> 
> This is a resend of v4 with slightly adjusted commit messages:
> 
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525016.html
> v2: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525069.html
> v3: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548338.html
> v4: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549252.html
> 
> It still survives the bootstrap and the regtest on x86_64-redhat-
> linux,
> s390x-redhat-linux and ppc64le-redhat-linux.  It also fixes [1].
> 
> I also tried the approach with moving .LASANPC closer to the function
> label and using FUNCTION_BOUNDARY instead of introducing
> CODE_LABEL_BOUNDARY, but the problem there is that it's hard to catch
> the moment where the function label is written.  Architectures can do
> it by calling ASM_OUTPUT_LABEL() or assemble_name() in
> ASM_DECLARE_FUNCTION_NAME(), ASM_OUTPUT_FUNCTION_LABEL() or
> TARGET_ASM_FUNCTION_PROLOGUE().  epiphany_start_function() does that
> twice, but passes the same decl to both calls.  Note that simply
> moving asan_function_start() to final_start_function_1() is not
> enough,
> since an architecture can write something after the function label.
> This all means that for this approach to work, all the architectures
> need to be adjusted, which looks like an overkill to me.
> 
> Best regards,
> Ilya
> 
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593666.html
> 
> 
> Ilya Leoshkevich (2):
>   asan: specify alignment for LASANPC labels
>   IBM zSystems: Define CODE_LABEL_BOUNDARY
> 
>  gcc/asan.cc                                    |  1 +
>  gcc/config/s390/s390.h                         |  3 +++
>  gcc/defaults.h                                 |  5 +++++
>  gcc/doc/tm.texi                                |  4 ++++
>  gcc/doc/tm.texi.in                             |  4 ++++
>  gcc/testsuite/gcc.target/s390/asan-no-gotoff.c | 15 +++++++++++++++
>  6 files changed, 32 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/s390/asan-no-gotoff.c
> 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v5 0/2] IBM zSystems: Improve storing asan frame_pc
  2022-09-27  0:23 [PATCH v5 0/2] IBM zSystems: Improve storing asan frame_pc Ilya Leoshkevich
                   ` (2 preceding siblings ...)
  2022-10-18  2:28 ` PING [PATCH v5 0/2] IBM zSystems: Improve storing asan frame_pc Ilya Leoshkevich
@ 2022-10-25 17:37 ` Jakub Jelinek
  3 siblings, 0 replies; 5+ messages in thread
From: Jakub Jelinek @ 2022-10-25 17:37 UTC (permalink / raw)
  To: Ilya Leoshkevich; +Cc: gcc-patches

On Tue, Sep 27, 2022 at 02:23:32AM +0200, Ilya Leoshkevich wrote:
> This is a resend of v4 with slightly adjusted commit messages:
> 
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525016.html
> v2: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525069.html
> v3: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548338.html
> v4: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549252.html
> 
> It still survives the bootstrap and the regtest on x86_64-redhat-linux,
> s390x-redhat-linux and ppc64le-redhat-linux.  It also fixes [1].
> 
> I also tried the approach with moving .LASANPC closer to the function
> label and using FUNCTION_BOUNDARY instead of introducing
> CODE_LABEL_BOUNDARY, but the problem there is that it's hard to catch
> the moment where the function label is written.  Architectures can do
> it by calling ASM_OUTPUT_LABEL() or assemble_name() in
> ASM_DECLARE_FUNCTION_NAME(), ASM_OUTPUT_FUNCTION_LABEL() or
> TARGET_ASM_FUNCTION_PROLOGUE().  epiphany_start_function() does that
> twice, but passes the same decl to both calls.  Note that simply
> moving asan_function_start() to final_start_function_1() is not enough,
> since an architecture can write something after the function label.
> This all means that for this approach to work, all the architectures
> need to be adjusted, which looks like an overkill to me.

Sorry for the delay.
I think the right fix is to follow on s390 and other arches what
has been done for x86 in https://gcc.gnu.org/PR98776
That changed not just .LASANPC labels, but also the debug related
labels from after the patchable area to before it.
And then .LASANPC label can just get FUNCTION_BOUNDARY alignment
set in the generic code.

	Jakub


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-10-25 17:37 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-27  0:23 [PATCH v5 0/2] IBM zSystems: Improve storing asan frame_pc Ilya Leoshkevich
2022-09-27  0:23 ` [PATCH v5 1/2] asan: specify alignment for LASANPC labels Ilya Leoshkevich
2022-09-27  0:23 ` [PATCH v5 2/2] IBM zSystems: Define CODE_LABEL_BOUNDARY Ilya Leoshkevich
2022-10-18  2:28 ` PING [PATCH v5 0/2] IBM zSystems: Improve storing asan frame_pc Ilya Leoshkevich
2022-10-25 17:37 ` Jakub Jelinek

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