On Tue, Jun 16, 2020 at 7:17 AM Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Tue, Jun 09, 2020 at 09:34:01AM -0700, H.J. Lu via Gcc-patches wrote:
> > > >         * gcc.target/i386/pr93492-3.c: Likewise.
> > > >         * gcc.target/i386/pr93492-5.c: Likewise.
>
> These tests FAIL on i686-linux.
> E.g. in the first one I see
>         .file   "pr93492-3.c"
>         .text
>         .globl  f10_endbr
>         .type   f10_endbr, @function
> f10_endbr:
> .LFB0:
>         .cfi_startproc
>         endbr32
>         .section        __patchable_function_entries,"aw",@progbits
>         .align 4
>         .long   .LPFE1
>         .text
> .LPFE1:
>         nop
> 1:      call    __fentry__
>         pushl   %ebp
>         .cfi_def_cfa_offset 8
>         .cfi_offset 5, -8
>         movl    %esp, %ebp
>         .cfi_def_cfa_register 5
>         popl    %ebp
>         .cfi_restore 5
>         .cfi_def_cfa 4, 4
>         ret
>         .cfi_endproc
> .LFE0:
>         .size   f10_endbr, .-f10_endbr
> so it doesn't match the scan regexp, because
>         call    __fentry__
> is not immediately followed by
>         ret
> As -pg is incompatible with -fomit-frame-pointer, I don't see anything wrong
> on that.

Can you take a look at

https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547992.html

It should fix it.

> Another thing in the test is that I don't think you can rely on
> .cfi_startproc actually being printed, you should add an effective target
> that will either check __GCC_HAVE_DWARF2_CFI_ASM macro definition, or check
> for presence of .cfi_startproc on some trivial function compiled with
> -fasynchronous-unwind-tables.
>

-mfentry and -fpatchable-function-entry= don't work on all targets.
Should I limit these tests to Linux?

-- 
H.J.

Reply via email to