mbox series

[v5,0/2] IBM zSystems: Improve storing asan frame_pc

Message ID 20220927002334.651057-1-iii@linux.ibm.com
Headers
Series IBM zSystems: Improve storing asan frame_pc |

Message

Ilya Leoshkevich Sept. 27, 2022, 12:23 a.m. UTC 
  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

Comments

Ilya Leoshkevich Oct. 18, 2022, 2:28 a.m. UTC | #1 
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
>
Jakub Jelinek Oct. 25, 2022, 5:37 p.m. UTC | #2 
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