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