* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
@ 2020-05-02 4:07 ` cvs-commit at gcc dot gnu.org
2020-05-07 11:56 ` jakub at gcc dot gnu.org
` (20 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-05-02 4:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
2020-05-02 4:07 ` [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full cvs-commit at gcc dot gnu.org
@ 2020-05-07 11:56 ` jakub at gcc dot gnu.org
2020-06-12 3:45 ` cvs-commit at gcc dot gnu.org
` (19 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-05-07 11:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
2020-05-02 4:07 ` [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full cvs-commit at gcc dot gnu.org
2020-05-07 11:56 ` jakub at gcc dot gnu.org
@ 2020-06-12 3:45 ` cvs-commit at gcc dot gnu.org
2020-06-12 3:49 ` hjl.tools at gmail dot com
` (18 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-06-12 3:45 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-06-12 3:45 ` cvs-commit at gcc dot gnu.org
@ 2020-06-12 3:49 ` hjl.tools at gmail dot com
2020-06-14 15:38 ` ro at gcc dot gnu.org
` (17 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2020-06-12 3:49 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2020-06-12 3:49 ` hjl.tools at gmail dot com
@ 2020-06-14 15:38 ` ro at gcc dot gnu.org
2020-06-14 15:47 ` hjl.tools at gmail dot com
` (16 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: ro at gcc dot gnu.org @ 2020-06-14 15:38 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2020-06-14 15:38 ` ro at gcc dot gnu.org
@ 2020-06-14 15:47 ` hjl.tools at gmail dot com
2020-06-14 16:52 ` iains at gcc dot gnu.org
` (15 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2020-06-14 15:47 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2020-06-14 15:47 ` hjl.tools at gmail dot com
@ 2020-06-14 16:52 ` iains at gcc dot gnu.org
2020-06-15 13:12 ` hjl.tools at gmail dot com
` (14 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: iains at gcc dot gnu.org @ 2020-06-14 16:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2020-06-14 16:52 ` iains at gcc dot gnu.org
@ 2020-06-15 13:12 ` hjl.tools at gmail dot com
2020-06-26 23:13 ` hjl.tools at gmail dot com
` (13 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2020-06-15 13:12 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2020-06-15 13:12 ` hjl.tools at gmail dot com
@ 2020-06-26 23:13 ` hjl.tools at gmail dot com
2020-07-10 12:57 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (12 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2020-06-26 23:13 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2020-06-26 23:13 ` hjl.tools at gmail dot com
@ 2020-07-10 12:57 ` ro at CeBiTec dot Uni-Bielefeld.DE
2020-07-10 13:56 ` hjl.tools at gmail dot com
` (11 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2020-07-10 12:57 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2020-07-10 12:57 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2020-07-10 13:56 ` hjl.tools at gmail dot com
2020-07-10 14:03 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (10 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2020-07-10 13:56 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2020-07-10 13:56 ` hjl.tools at gmail dot com
@ 2020-07-10 14:03 ` ro at CeBiTec dot Uni-Bielefeld.DE
2020-07-10 14:04 ` hjl.tools at gmail dot com
` (9 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2020-07-10 14:03 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2020-07-10 14:03 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2020-07-10 14:04 ` hjl.tools at gmail dot com
2020-07-10 14:06 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (8 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2020-07-10 14:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2020-07-10 14:04 ` hjl.tools at gmail dot com
@ 2020-07-10 14:06 ` ro at CeBiTec dot Uni-Bielefeld.DE
2020-07-10 14:12 ` hjl.tools at gmail dot com
` (7 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2020-07-10 14:06 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2020-07-10 14:06 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2020-07-10 14:12 ` hjl.tools at gmail dot com
2020-07-10 14:16 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (6 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2020-07-10 14:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (14 preceding siblings ...)
2020-07-10 14:12 ` hjl.tools at gmail dot com
@ 2020-07-10 14:16 ` ro at CeBiTec dot Uni-Bielefeld.DE
2020-07-10 14:33 ` hjl.tools at gmail dot com
` (5 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2020-07-10 14:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (15 preceding siblings ...)
2020-07-10 14:16 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2020-07-10 14:33 ` hjl.tools at gmail dot com
2020-07-10 14:41 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (4 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2020-07-10 14:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (16 preceding siblings ...)
2020-07-10 14:33 ` hjl.tools at gmail dot com
@ 2020-07-10 14:41 ` ro at CeBiTec dot Uni-Bielefeld.DE
2020-07-10 15:53 ` mikestump at comcast dot net
` (3 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2020-07-10 14:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (17 preceding siblings ...)
2020-07-10 14:41 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2020-07-10 15:53 ` mikestump at comcast dot net
2020-07-10 21:54 ` hjl.tools at gmail dot com
` (2 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: mikestump at comcast dot net @ 2020-07-10 15:53 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (18 preceding siblings ...)
2020-07-10 15:53 ` mikestump at comcast dot net
@ 2020-07-10 21:54 ` hjl.tools at gmail dot com
2020-07-12 12:06 ` cvs-commit at gcc dot gnu.org
2020-07-12 12:07 ` hjl.tools at gmail dot com
21 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2020-07-10 21:54 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (19 preceding siblings ...)
2020-07-10 21:54 ` hjl.tools at gmail dot com
@ 2020-07-12 12:06 ` cvs-commit at gcc dot gnu.org
2020-07-12 12:07 ` hjl.tools at gmail dot com
21 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-07-12 12:06 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
[not found] <bug-93492-4@http.gcc.gnu.org/bugzilla/>
` (20 preceding siblings ...)
2020-07-12 12:06 ` cvs-commit at gcc dot gnu.org
@ 2020-07-12 12:07 ` hjl.tools at gmail dot com
21 siblings, 0 replies; 22+ messages in thread
From: hjl.tools at gmail dot com @ 2020-07-12 12:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread