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
