[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:6607bdd99994c834f92fce924abdaea3405f62dc

commit r11-23-g6607bdd99994c834f92fce924abdaea3405f62dc
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri May 1 21:03:10 2020 -0700

    Add patch_area_size and patch_area_entry to crtl

    Currently patchable area is at the wrong place.  It is placed immediately
    after function label and before .cfi_startproc.  A backend should be able
    to add a pseudo patchable area instruction durectly into RTL.  This patch
    adds patch_area_size and patch_area_entry to crtl so that the patchable
    area info is available in RTL passes.

    It also limits patch_area_size and patch_area_entry to 65535, which is
    a reasonable maximum size for patchable area.

    gcc/

            PR target/93492
            * cfgexpand.c (pass_expand::execute): Set crtl->patch_area_size
            and crtl->patch_area_entry.
            * emit-rtl.h (rtl_data): Add patch_area_size and patch_area_entry.
            * opts.c (common_handle_option): Limit
            function_entry_patch_area_size and function_entry_patch_area_start
            to USHRT_MAX.  Fix a typo in error message.
            * varasm.c (assemble_start_function): Use crtl->patch_area_size
            and crtl->patch_area_entry.
            * doc/invoke.texi: Document the maximum value for
            -fpatchable-function-entry.

    gcc/c-family/

            PR target/93492
            * c-attribs.c (handle_patchable_function_entry_attribute): Limit
            value to USHRT_MAX (65535).

    gcc/testsuite/

            PR target/93492
            * c-c++-common/patchable_function_entry-error-1.c: New test.
            * c-c++-common/patchable_function_entry-error-2.c: Likewise.
            * c-c++-common/patchable_function_entry-error-3.c: Likewise.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.0                        |10.2

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.1 has been released.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:3dcea658c9e2ac84f0726e679fd7d3b14f9106f0

commit r11-1245-g3dcea658c9e2ac84f0726e679fd7d3b14f9106f0
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Mon Feb 3 10:22:57 2020 -0800

    x86: Add UNSPECV_PATCHABLE_AREA

    Currently patchable area is at the wrong place.  It is placed immediately
    after function label, before both .cfi_startproc and ENDBR.  This patch
    adds UNSPECV_PATCHABLE_AREA for pseudo patchable area instruction and
    changes ENDBR insertion pass to also insert patchable area instruction.
    TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY is defined to avoid placing
    patchable area before .cfi_startproc and ENDBR.

    gcc/

            PR target/93492
            * config/i386/i386-features.c (rest_of_insert_endbranch):
            Renamed to ...
            (rest_of_insert_endbr_and_patchable_area): Change return type
            to void. Add need_endbr and patchable_area_size arguments.
            Don't call timevar_push nor timevar_pop.  Replace
            endbr_queued_at_entrance with insn_queued_at_entrance.  Insert
            UNSPECV_PATCHABLE_AREA for patchable area.
            (pass_data_insert_endbranch): Renamed to ...
            (pass_data_insert_endbr_and_patchable_area): This.  Change
            pass name to endbr_and_patchable_area.
            (pass_insert_endbranch): Renamed to ...
            (pass_insert_endbr_and_patchable_area): This.  Add need_endbr
            and patchable_area_size;.
            (pass_insert_endbr_and_patchable_area::gate): Set and check
            need_endbr and patchable_area_size.
            (pass_insert_endbr_and_patchable_area::execute): Call
            timevar_push and timevar_pop.  Pass need_endbr and
            patchable_area_size to rest_of_insert_endbr_and_patchable_area.
            (make_pass_insert_endbranch): Renamed to ...
            (make_pass_insert_endbr_and_patchable_area): This.
            * config/i386/i386-passes.def: Replace pass_insert_endbranch
            with pass_insert_endbr_and_patchable_area.
            * config/i386/i386-protos.h (ix86_output_patchable_area): New.
            (make_pass_insert_endbranch): Renamed to ...
            (make_pass_insert_endbr_and_patchable_area): This.
            * config/i386/i386.c (ix86_asm_output_function_label): Set
            function_label_emitted to true.
            (ix86_print_patchable_function_entry): New function.
            (ix86_output_patchable_area): Likewise.
            (x86_function_profiler): Replace endbr_queued_at_entrance with
            insn_queued_at_entrance.  Generate ENDBR only for TYPE_ENDBR.
            Call ix86_output_patchable_area to generate patchable area if
            needed.
            (TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY): New.
            * config/i386/i386.h (queued_insn_type): New.
            (machine_function): Add function_label_emitted.  Replace
            endbr_queued_at_entrance with insn_queued_at_entrance.
            * config/i386/i386.md (UNSPECV_PATCHABLE_AREA): New.
            (patchable_area): New.

    gcc/testsuite/

            PR target/93492
            * gcc.target/i386/pr93492-1.c: New test.
            * gcc.target/i386/pr93492-2.c: Likewise.
            * gcc.target/i386/pr93492-3.c: Likewise.
            * gcc.target/i386/pr93492-4.c: Likewise.
            * gcc.target/i386/pr93492-5.c: Likewise.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|10.2                        |11.0

--- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed for GCC 11.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at gcc dot gnu.org
         Resolution|FIXED                       |---
             Status|RESOLVED                    |REOPENED

--- Comment #20 from Rainer Orth <ro at gcc dot gnu.org> ---
Several of the new testcases FAIL in various configurations:

* On i386-pc-solaris2.11 with the native assembler (both 32 and 64-bit):

+FAIL: gcc.target/i386/pr93492-2.c scan-assembler
\\t.cfi_startproc\\n\\tendbr(32|64)\\n.*.LPFE1:\\n\\tnop\\n\\tret\\n
+FAIL: gcc.target/i386/pr93492-3.c scan-assembler
\\t.cfi_startproc\\n\\tendbr(32|64)\\n.*.LPFE1:\\n\\tnop\\n1:\\tcall\\t__fentry__\\n\\tret\\n
+FAIL: gcc.target/i386/pr93492-4.c scan-assembler
\\t.cfi_startproc\\n.*.LPFE1:\\n\\tnop\\n\\tret\\n
+FAIL: gcc.target/i386/pr93492-5.c scan-assembler
\\t.cfi_startproc\\n.*.LPFE1:\\n\\tnop\\n1:\\tcall\\t__fentry__\\n\\tret\\n

  Please note that while /bin/as *does* accept .cfi_* directives, gcc doesn't
  emit them because there are bugs in as' support.

* On i386-pc-solaris2.11 with gas (both 32 and 64-bit):

+FAIL: gcc.target/i386/pr93492-3.c scan-assembler
\\t.cfi_startproc\\n\\tendbr(32|64)\\n.*.LPFE1:\\n\\tnop\\n1:\\tcall\\t__fentry__\\n\\tret\\n
+FAIL: gcc.target/i386/pr93492-5.c scan-assembler
\\t.cfi_startproc\\n.*.LPFE1:\\n\\tnop\\n1:\\tcall\\t__fentry__\\n\\tret\\n

  E.g. the 32-bit pr93492-3.s has

        .cfi_startproc
        .data
        .align 4
.LP0:
        .long   0
        .text
        endbr32
        .section        __patchable_function_entries,"aw",@progbits
        .align 4
        .long   .LPFE1
        .text
.LPFE1:
        nop
        movl    $.LP0,%edx
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

* On x86_64-apple-darwin11.4.2 (both 32 and 64-bit):

FAIL: gcc.target/i386/pr93492-1.c check-function-bodies f10_endbr
FAIL: gcc.target/i386/pr93492-1.c check-function-bodies f10_none
FAIL: gcc.target/i386/pr93492-1.c check-function-bodies f11_endbr
FAIL: gcc.target/i386/pr93492-1.c check-function-bodies f11_none
FAIL: gcc.target/i386/pr93492-1.c check-function-bodies f21_endbr
FAIL: gcc.target/i386/pr93492-1.c check-function-bodies f21_none
FAIL: gcc.target/i386/pr93492-2.c scan-assembler
\\t.cfi_startproc\\n\\tendbr(32|64)\\n.*.LPFE1:\\n\\tnop\\n\\tret\\n
FAIL: gcc.target/i386/pr93492-4.c scan-assembler
\\t.cfi_startproc\\n.*.LPFE1:\\n\\tnop\\n\\tret\\n

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iains at gcc dot gnu.org,
                   |                            |mikestump at comcast dot net
         Depends on|                            |95655

--- Comment #21 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Rainer Orth from comment #20)
> Several of the new testcases FAIL in various configurations:
> 
> * On i386-pc-solaris2.11 with the native assembler (both 32 and 64-bit):
> 
> +FAIL: gcc.target/i386/pr93492-2.c scan-assembler
> \\t.cfi_startproc\\n\\tendbr(32|64)\\n.*.LPFE1:\\n\\tnop\\n\\tret\\n
> +FAIL: gcc.target/i386/pr93492-3.c scan-assembler
> \\t.cfi_startproc\\n\\tendbr(32|64)\\n.*.LPFE1:\\n\\tnop\\n1:
> \\tcall\\t__fentry__\\n\\tret\\n
> +FAIL: gcc.target/i386/pr93492-4.c scan-assembler
> \\t.cfi_startproc\\n.*.LPFE1:\\n\\tnop\\n\\tret\\n
> +FAIL: gcc.target/i386/pr93492-5.c scan-assembler
> \\t.cfi_startproc\\n.*.LPFE1:\\n\\tnop\\n1:\\tcall\\t__fentry__\\n\\tret\\n
> 
>   Please note that while /bin/as *does* accept .cfi_* directives, gcc doesn't
>   emit them because there are bugs in as' support.
> 
> * On i386-pc-solaris2.11 with gas (both 32 and 64-bit):
> 
> +FAIL: gcc.target/i386/pr93492-3.c scan-assembler
> \\t.cfi_startproc\\n\\tendbr(32|64)\\n.*.LPFE1:\\n\\tnop\\n1:
> \\tcall\\t__fentry__\\n\\tret\\n
> +FAIL: gcc.target/i386/pr93492-5.c scan-assembler
> \\t.cfi_startproc\\n.*.LPFE1:\\n\\tnop\\n1:\\tcall\\t__fentry__\\n\\tret\\n
> 
>   E.g. the 32-bit pr93492-3.s has
> 
>         .cfi_startproc
>         .data
>         .align 4
> .LP0:
>         .long   0
>         .text
>         endbr32
>         .section        __patchable_function_entries,"aw",@progbits
>         .align 4
>         .long   .LPFE1
>         .text
> .LPFE1:
>         nop
>         movl    $.LP0,%edx
> 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

This is PR 95655.

> * On x86_64-apple-darwin11.4.2 (both 32 and 64-bit):
> 
> FAIL: gcc.target/i386/pr93492-1.c check-function-bodies f10_endbr
> FAIL: gcc.target/i386/pr93492-1.c check-function-bodies f10_none
> FAIL: gcc.target/i386/pr93492-1.c check-function-bodies f11_endbr
> FAIL: gcc.target/i386/pr93492-1.c check-function-bodies f11_none
> FAIL: gcc.target/i386/pr93492-1.c check-function-bodies f21_endbr
> FAIL: gcc.target/i386/pr93492-1.c check-function-bodies f21_none
> FAIL: gcc.target/i386/pr93492-2.c scan-assembler
> \\t.cfi_startproc\\n\\tendbr(32|64)\\n.*.LPFE1:\\n\\tnop\\n\\tret\\n
> FAIL: gcc.target/i386/pr93492-4.c scan-assembler
> \\t.cfi_startproc\\n.*.LPFE1:\\n\\tnop\\n\\tret\\n

CC darwin maintainers.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95655
[Bug 95655] -mfentry -pg generates extra push/pop

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

--- Comment #22 from Iain Sandoe <iains at gcc dot gnu.org> ---
I looked yesterday and, as of Xcode 11.5, the patchable_function_entry
attribute is not recognised but the system tools.

That means, for now, that there is no de-facto ABI for patchable functions on
Mach-O/Darwin platforms (regardless of the fact that upstream clang accepts the
attribute for Darwin targets).

The "old" patchable function option (-mfix-and-continue) is recognised but is a
NOP for modern Darwin.

My plan is to skip the test(s) on Darwin - if there are enough test(s) then we
should have a target-supports for the facility.

I note in passing thet the target hook is not terribly friendly - the syntax
error on Darwin is only because of the hard-wired assumption that named
sections are ELF-named-sections.  Which means that we will (when the ABI is
settled) have to re-write the whole hook potentially for one line of code
difference.

In general, for a compiler like GCC that is supposed to support many targets,
it would be a Good Idea is folks would not assume that everything is ELF.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |WAITING

--- Comment #23 from H.J. Lu <hjl.tools at gmail dot com> ---
Do -fpatchable-function-entry and -mfentry work on Solaris?

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492
Bug 93492 depends on bug 95655, which changed state.

Bug 95655 Summary: -mfentry -pg generates extra push/pop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95655

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #23 from H.J. Lu <hjl.tools at gmail dot com> ---
> Do -fpatchable-function-entry and -mfentry work on Solaris?

I don't have the slightest idea what that would mean, and the
descriptions of the options don't leave me any wiser.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

--- Comment #25 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #24)
> > --- Comment #23 from H.J. Lu <hjl.tools at gmail dot com> ---
> > Do -fpatchable-function-entry and -mfentry work on Solaris?
> 
> I don't have the slightest idea what that would mean, and the
> descriptions of the options don't leave me any wiser.

-fpatchable-function-entry and -mfentry generate special instruction
sequence at function entry.  Does Solaris support such special
instruction sequence?

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #25 from H.J. Lu <hjl.tools at gmail dot com> ---
> -fpatchable-function-entry and -mfentry generate special instruction
> sequence at function entry.  Does Solaris support such special
> instruction sequence?

Where would such support live?  The kernel?  libc.so.1?  ld.so.1?

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

--- Comment #27 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #26)
> > --- Comment #25 from H.J. Lu <hjl.tools at gmail dot com> ---
> > -fpatchable-function-entry and -mfentry generate special instruction
> > sequence at function entry.  Does Solaris support such special
> > instruction sequence?
> 
> Where would such support live?  The kernel?  libc.so.1?  ld.so.1?

-fpatchable-function-entry and -mfentry are used in Linux kernel.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #27 from H.J. Lu <hjl.tools at gmail dot com> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #26)
>> > --- Comment #25 from H.J. Lu <hjl.tools at gmail dot com> ---
>> > -fpatchable-function-entry and -mfentry generate special instruction
>> > sequence at function entry.  Does Solaris support such special
>> > instruction sequence?
>> 
>> Where would such support live?  The kernel?  libc.so.1?  ld.so.1?
>
> -fpatchable-function-entry and -mfentry are used in Linux kernel.

In that case: no.  The Solaris kernel can (and is) compiled both by gcc
and Studio cc, and the latter certainly hasn't anything similar.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

--- Comment #29 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #28)
> > --- Comment #27 from H.J. Lu <hjl.tools at gmail dot com> ---
> > (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #26)
> >> > --- Comment #25 from H.J. Lu <hjl.tools at gmail dot com> ---
> >> > -fpatchable-function-entry and -mfentry generate special instruction
> >> > sequence at function entry.  Does Solaris support such special
> >> > instruction sequence?
> >> 
> >> Where would such support live?  The kernel?  libc.so.1?  ld.so.1?
> >
> > -fpatchable-function-entry and -mfentry are used in Linux kernel.
> 
> In that case: no.  The Solaris kernel can (and is) compiled both by gcc
> and Studio cc, and the latter certainly hasn't anything similar.

Then just skip these tests on Solaris.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

--- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #29 from H.J. Lu <hjl.tools at gmail dot com> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #28)
>> > --- Comment #27 from H.J. Lu <hjl.tools at gmail dot com> ---
>> > (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #26)
>> >> > --- Comment #25 from H.J. Lu <hjl.tools at gmail dot com> ---
>> >> > -fpatchable-function-entry and -mfentry generate special instruction
>> >> > sequence at function entry.  Does Solaris support such special
>> >> > instruction sequence?
>> >> 
>> >> Where would such support live?  The kernel?  libc.so.1?  ld.so.1?
>> >
>> > -fpatchable-function-entry and -mfentry are used in Linux kernel.
>> 
>> In that case: no.  The Solaris kernel can (and is) compiled both by gcc
>> and Studio cc, and the latter certainly hasn't anything similar.
>
> Then just skip these tests on Solaris.

If this is a Linux-only feature, shouldn't the tests rather be
restricted to Linux instead?  It certainly also fails on freebsd,
darwin, mingw and whatever more.  Having to skip it on all those
explicitly (until we discover the next target we forgot about) seems
just the wrong way round.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

--- Comment #31 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #30)
> > --- Comment #29 from H.J. Lu <hjl.tools at gmail dot com> ---
> > (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #28)
> >> > --- Comment #27 from H.J. Lu <hjl.tools at gmail dot com> ---
> >> > (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #26)
> >> >> > --- Comment #25 from H.J. Lu <hjl.tools at gmail dot com> ---
> >> >> > -fpatchable-function-entry and -mfentry generate special instruction
> >> >> > sequence at function entry.  Does Solaris support such special
> >> >> > instruction sequence?
> >> >> 
> >> >> Where would such support live?  The kernel?  libc.so.1?  ld.so.1?
> >> >
> >> > -fpatchable-function-entry and -mfentry are used in Linux kernel.
> >> 
> >> In that case: no.  The Solaris kernel can (and is) compiled both by gcc
> >> and Studio cc, and the latter certainly hasn't anything similar.
> >
> > Then just skip these tests on Solaris.
> 
> If this is a Linux-only feature, shouldn't the tests rather be
> restricted to Linux instead?  It certainly also fails on freebsd,
> darwin, mingw and whatever more.  Having to skip it on all those
> explicitly (until we discover the next target we forgot about) seems
> just the wrong way round.


These features aren't Linux specific.  But they do require special
sequence at function entrance.  Solaris has a different function entry
which may not work with these features.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

--- Comment #32 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #31 from H.J. Lu <hjl.tools at gmail dot com> ---

>> If this is a Linux-only feature, shouldn't the tests rather be
>> restricted to Linux instead?  It certainly also fails on freebsd,
>> darwin, mingw and whatever more.  Having to skip it on all those
>> explicitly (until we discover the next target we forgot about) seems
>> just the wrong way round.
>
> These features aren't Linux specific.  But they do require special
> sequence at function entrance.  Solaris has a different function entry
> which may not work with these features.

Neither do all the other x86 targets listed above.  I still think that
the list of targets that *can* support this test is considerably shorter
than the one that don't.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[mikestump at comcast dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

--- Comment #33 from Mike Stump <mikestump at comcast dot net> ---
Please, unless you expect it to work in an OS independent way, please
conditionalize on the systems it is known to work on, meaning, it important for
it to work on it, you think all the work for it to work on those systems has
been done.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

--- Comment #34 from H.J. Lu <hjl.tools at gmail dot com> ---
A patch is posted at

https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549880.html

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

--- Comment #35 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:267891bd3c7ce3e16662eb2be7273f0bc8be9e7e

commit r11-2041-g267891bd3c7ce3e16662eb2be7273f0bc8be9e7e
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri Jul 10 14:50:03 2020 -0700

    x86: Require Linux target for PR target/93492 tests

    Since -fpatchable-function-entry is only supported on Linux and used by
    Linux kernel, require Linux target for PR target/93492 tests.

            PR target/93492
            * gcc.target/i386/pr93492-1.c: Require Linux target.
            * gcc.target/i386/pr93492-2.c: Likewise.
            * gcc.target/i386/pr93492-3.c: Likewise.
            * gcc.target/i386/pr93492-4.c: Likewise.
            * gcc.target/i386/pr93492-5.c: Likewise.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #36 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed for GCC 11.