Re: [PATCH v5 0/2] IBM zSystems: Improve storing asan frame_pc
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
PING [PATCH v5 0/2] IBM zSystems: Improve storing asan frame_pc
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 >
[PATCH v5 0/2] IBM zSystems: Improve storing asan frame_pc
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