RE: [PATCH 2/2] x86: Update __CET__ check

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Tuesday, April 24, 2018 7:08 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; Uros Bizjak
> <ubiz...@gmail.com>
> Subject: [PATCH 2/2] x86: Update __CET__ check
> 
> __CET__ has been changed by revision 259522:
> 
> commit d59cfa9a4064339cf2bd2da828c4c133f13e57f0
> Author: hjl <hjl@138bc75d-0d04-0410-961f-82ee72b054a4>
> Date:   Fri Apr 20 13:30:13 2018 +
> 
> Define __CET__ for -fcf-protection and remove -mibt
> 
> to
> 
> (__CET__ & 1) != 0: -fcf-protection=branch or -fcf-protection=full
> (__CET__ & 2) != 0: -fcf-protection=return or -fcf-protection=full
> 
> We should check (__CET__ & 2) != 0 for shadow stack.
> 
> libgcc/
> 
>   * config/i386/linux-unwind.h: Add (__CET__ & 2) != 0 check
>   when including "config/i386/shadow-stack-unwind.h".
> 
> libitm/
> 
>   * config/x86/sjlj.S (_ITM_beginTransaction): Add
>   (__CET__ & 2) != 0 check for shadow stack.
>   (GTM_longjmp): Likewise.
> ---
>  libgcc/config/i386/linux-unwind.h | 2 +-
>  libitm/config/x86/sjlj.S  | 8 
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/libgcc/config/i386/linux-unwind.h b/libgcc/config/i386/linux-
> unwind.h
> index f1f52334d8d..ea838e4e47b 100644
> --- a/libgcc/config/i386/linux-unwind.h
> +++ b/libgcc/config/i386/linux-unwind.h
> @@ -23,7 +23,7 @@ see the files COPYING3 and COPYING.RUNTIME
> respectively.  If not, see
>  <http://www.gnu.org/licenses/>.  */
> 
>  /* Unwind shadow stack for -fcf-protection -mshstk.  */
> -#if defined __SHSTK__ && defined __CET__
> +#if defined __SHSTK__ && defined __CET__ && (__CET__ & 2) != 0
>  # include "config/i386/shadow-stack-unwind.h"
>  #endif
> 
> diff --git a/libitm/config/x86/sjlj.S b/libitm/config/x86/sjlj.S
> index 2345b2f4ec4..e5cdbab48a7 100644
> --- a/libitm/config/x86/sjlj.S
> +++ b/libitm/config/x86/sjlj.S
> @@ -141,7 +141,7 @@ SYM(_ITM_beginTransaction):
>   movq%r15, -24(%rax)
>   xorq%rdx, %rdx
>   /* Save zero or shadow stack pointer in the new field.  */
> -#if defined(__SHSTK__) && defined(__CET__)
> +#if defined __SHSTK__ && defined __CET__ && (__CET__ & 2) != 0
>   rdsspq  %rdx
>  #endif
>   movq%rdx, -16(%rax)
> @@ -177,7 +177,7 @@ SYM(_ITM_beginTransaction):
>   movl%ebp, 20(%esp)
>   xorl%edx, %edx
>   /* Save zero or shadow stack pointer in the new field.  */
> -#if defined(__SHSTK__) && defined(__CET__)
> +#if defined __SHSTK__ && defined __CET__ && (__CET__ & 2) != 0
>   rdsspd  %edx
>  #endif
>   movl%edx, 24(%esp)
> @@ -221,7 +221,7 @@ SYM(GTM_longjmp):
>   cfi_offset(%rip, 64)
>   cfi_register(%rsp, %rcx)
>   movq%rcx, %rsp
> -#if defined(__SHSTK__) && defined(__CET__)
> +#if defined __SHSTK__ && defined __CET__ && (__CET__ & 2) != 0
>   /* Check if Shadow Stack is enabled.  */
>   xorq%rcx, %rcx
>   rdsspq  %rcx
> @@ -259,7 +259,7 @@ SYM(GTM_longjmp):
>   cfi_offset(%eip, 24)
>   cfi_register(%esp, %ecx)
>   movl%ecx, %esp
> -#if defined(__SHSTK__) && defined(__CET__)
> +#if defined __SHSTK__ && defined __CET__ && (__CET__ & 2) != 0
>   /* Check if Shadow Stack is enabled.  */
>   xorl%ecx, %ecx
>   rdsspd  %ecx
> --
> 2.14.3

OK.

Igor

RE: [PATCH 1/2] x86/CET: Add -fcf-protection to STAGE4_CFLAGS

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Tuesday, April 24, 2018 7:08 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; Uros Bizjak
> <ubiz...@gmail.com>
> Subject: [PATCH 1/2] x86/CET: Add -fcf-protection to STAGE4_CFLAGS
> 
> Since profiledbootstrap uses
> 
> STAGEfeedback_CFLAGS = $(STAGE4_CFLAGS) -fprofile-use
> 
> add
> 
> STAGE4_CFLAGS += -fcf-protection -mcet
> 
> to bootstrap-cet.mk to support profiledbootstrap with CET.
> 
>   PR bootstrap/85490
>   * bootstrap-cet.mk (STAGE4_CFLAGS): New.
> ---
>  config/bootstrap-cet.mk | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/config/bootstrap-cet.mk b/config/bootstrap-cet.mk
> index b5dee601a3f..6ef1ba279cd 100644
> --- a/config/bootstrap-cet.mk
> +++ b/config/bootstrap-cet.mk
> @@ -1,4 +1,5 @@
> -# This option enables -fcf-protection for stage2 and stage3.
> +# This option enables -fcf-protection for stage2, stage3 and stage4.
> 
>  STAGE2_CFLAGS += -fcf-protection
>  STAGE3_CFLAGS += -fcf-protection
> +STAGE4_CFLAGS += -fcf-protection
> --
> 2.14.3

OK.

Igor

RE: [PATCH 0/5] x86/CET: Remove the -mcet command-lint option

[Tsimbalist, Igor V]

> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Sunday, April 22, 2018 3:48 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; Uros Bizjak
> <ubiz...@gmail.com>
> Subject: [PATCH 0/5] x86/CET: Remove the -mcet command-lint option
> 
> With revision 259496:
> 
> commit b1384095a7c1d06a44b70853372ebe037b2f7867
> Author: hjl <hjl@138bc75d-0d04-0410-961f-82ee72b054a4>
> Date:   Thu Apr 19 15:15:04 2018 +
> 
> x86: Enable -fcf-protection with multi-byte NOPs
> 
> -fcf-protection no longer depens on -mcet and with revision 259522:
> 
> commit d59cfa9a4064339cf2bd2da828c4c133f13e57f0
> Author: hjl <hjl@138bc75d-0d04-0410-961f-82ee72b054a4>
> Date:   Fri Apr 20 13:30:13 2018 +
> 
> Define __CET__ for -fcf-protection and remove -mibt
> 
> -mcet becomes an alias for -mshstk.
> 
> To enable shadow stack protection in a program, -fcf-protection=return
> must be used to compile the program.  -mcet/-mshstk are used to enable
> shadow stack intrinsics to IMPLEMENT shadow stack, not to ENABLE shadow
> stack protection.  Since -mcet won't get any shadow stack protection,
> -mcet will only lead user confusions.  This set of patches removes -mcet
> from GCC 8.
> 
> H.J. Lu (5):
>   x86/CET: Build target libraries with -mshstk
>   Regenerate configure of target libraries
>   Don't bootstrap GCC with -mcet
>   x86/CET tests: Remove -mcet/-mno-cet or replace -mcet with -mshstk
>   x86/CET: Remove the -mcet command-lint option
> 
>  config/bootstrap-cet.mk|  6 +--
>  config/cet.m4  |  2 +-
>  gcc/common/config/i386/i386-common.c   |  1 -
>  gcc/config/i386/i386.opt   |  5 ---
>  gcc/doc/install.texi   |  4 +-
>  gcc/doc/invoke.texi| 10 +
>  gcc/testsuite/g++.dg/cet-notrack-1.C   |  2 +-
>  gcc/testsuite/g++.dg/torture/pr85334.C |  2 +-
>  gcc/testsuite/gcc.dg/pr85388-1.c   |  2 +-
>  gcc/testsuite/gcc.dg/pr85388-2.c   |  2 +-
>  gcc/testsuite/gcc.dg/pr85388-3.c   |  2 +-
>  gcc/testsuite/gcc.dg/pr85388-4.c   |  2 +-
>  gcc/testsuite/gcc.dg/pr85388-5.c   |  2 +-
>  gcc/testsuite/gcc.dg/pr85388-6.c   |  4 +-
>  gcc/testsuite/gcc.dg/torture/pr85397-1.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/attr-nocf-check-1a.c |  2 +-
>  gcc/testsuite/gcc.target/i386/attr-nocf-check-3a.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-intrin-10.c  |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-intrin-3.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-intrin-5.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-intrin-6.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-intrin-7.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-intrin-8.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-intrin-9.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-label-2.c|  2 +-
>  gcc/testsuite/gcc.target/i386/cet-label-3.c| 16 
>  gcc/testsuite/gcc.target/i386/cet-label.c  |  4 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-1a.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-1b.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-2a.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-2b.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-3.c  |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-4a.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-4b.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-5a.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-5b.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-6a.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-6b.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-7.c  |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-icf-2.c  |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-icf-4.c  |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-property-1.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-property-2.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-property-3.c | 11 -
>  gcc/testsuite/gcc.target/i386/cet-rdssp-1.c|  2 +-
>  gcc/testsuite/gcc.target/i386/cet-sjlj-1.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-sjlj-2.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-sjlj-3.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-sjlj-4.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-sjlj-5.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-sjlj-6a.c|  2 +-
>  

RE: [PATCH] x86/cet: Use unsigned integer to unwind shadow stack

[Tsimbalist, Igor V]

> -Original Message-
> From: Lu, Hongjiu
> Sent: Monday, April 23, 2018 1:56 PM
> To: gccpat...@intel.com
> Cc: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; Uros Bizjak
> <ubiz...@gmail.com>
> Subject: [PATCH] x86/cet: Use unsigned integer to unwind shadow stack
> 
> Use unsigned integer to unwind shadow stack by replacing jle with jbe and
> jg with ja.
> 
> OK for trunk?

OK.

Igor

> H.J.
> 
>   PR target/85489
>   * config/x86/sjlj.S (GTM_longjmp): Replace jle/jg with jbe/ja.
> ---
>  libitm/config/x86/sjlj.S | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/libitm/config/x86/sjlj.S b/libitm/config/x86/sjlj.S
> index 3cac9099c9e..e5cdbab48a7 100644
> --- a/libitm/config/x86/sjlj.S
> +++ b/libitm/config/x86/sjlj.S
> @@ -235,7 +235,7 @@ SYM(GTM_longjmp):
>   /* If # of frames is greater 255 then loop
>  and adjust.  */
>   cmpq$255, %rcx
> - jle .L3
> + jbe .L3
>   movl$255, %edi
>   .p2align 4,,10
>   .p2align 3
> @@ -243,7 +243,7 @@ SYM(GTM_longjmp):
>   incsspq %rdi
>   subq$255, %rcx
>   cmpq$255, %rcx
> - jg  .L4
> + ja  .L4
>  .L3:
>   incsspq %rcx
>  .L1:
> @@ -273,7 +273,7 @@ SYM(GTM_longjmp):
>   /* If # of frames is greater 255 then loop
>  and adjust.  */
>   cmpl$255, %ecx
> - jle .L3
> + jbe .L3
>   pushl   %eax
>   movl$255, %eax
>   .p2align 4,,10
> @@ -282,7 +282,7 @@ SYM(GTM_longjmp):
>   incsspd %eax
>   subl$255, %ecx
>   cmpl$255, %ecx
> - jg  .L4
> + ja  .L4
>   popl%eax
>  .L3:
>   incsspd %ecx
> --
> 2.14.3

RE: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Tsimbalist, Igor V]

> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Friday, April 20, 2018 1:15 PM
> To: Jakub Jelinek <ja...@redhat.com>
> Cc: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; Richard Biener
> <richard.guent...@gmail.com>; Uros Bizjak <ubiz...@gmail.com>; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs
> 
> On Fri, Apr 20, 2018 at 09:39:58AM +0200, Jakub Jelinek wrote:
> > On Fri, Apr 20, 2018 at 06:25:10AM +, Tsimbalist, Igor V wrote:
> > > > Something like this?
> > >
> > > Shouldn't this
> > >
> > > -# ifdef __IBT__
> > > +# if (__CET__ & 1) != 0
> > >
> > > Be as
> > >
> > > -# ifdef __IBT__
> > > +#ifdef __CET__
> > > +# if (__CET__ & 1) != 0
> > >
> > > OK otherwise.
> >
> > Only if you use -Wundef warning (not part of -Wall or -W) and, if this
> > is a system header, only with -Wundef -Wsystem-headers.
> > But perhaps it doesn't hurt to wrap it.
> >
> > Jakub
> 
> Here is the patch.  OK for trunk?
> 
> Thanks.

OK.

Igor

> 
> H.J.
> ---
> With revision 259496:
> 
> commit b1384095a7c1d06a44b70853372ebe037b2f7867
> Author: hjl <hjl@138bc75d-0d04-0410-961f-82ee72b054a4>
> Date:   Thu Apr 19 15:15:04 2018 +
> 
> x86: Enable -fcf-protection with multi-byte NOPs
> 
> -mibt does nothing and can be removed.  Define __CET__ to indicate level
> protection with -fcf-protection:
> 
> (__CET__ & 1) != 0: -fcf-protection=branch or -fcf-protection=full
> (__CET__ & 2) != 0: -fcf-protection=return or -fcf-protection=full
> 
> gcc/
> 
>   PR target/85469
>   * common/config/i386/i386-common.c
> (OPTION_MASK_ISA_IBT_SET):
>   Removed.
>   (OPTION_MASK_ISA_IBT_UNSET): Likewise.
>   (ix86_handle_option): Don't handle OPT_mibt.
>   * config/i386/cet.h: Check __CET__ instead of __IBT__ and
>   __SHSTK__.
>   * config/i386/driver-i386.c (host_detect_local_cpu): Remove
>   has_ibt and ibt.
>   * config/i386/i386-c.c (ix86_target_macros_internal): Don't
>   check OPTION_MASK_ISA_IBT nor flag_cf_protection.
>   (ix86_target_macros): Define __CET__ with flag_cf_protection
>   for -fcf-protection.
>   * config/i386/i386.c (isa2_opts): Remove -mibt.
>   * config/i386/i386.h (TARGET_IBT): Removed.
>   (TARGET_IBT_P): Likewise.
>   (ix86_valid_target_attribute_inner_p): Don't check OPT_mibt.
>   * config/i386/i386.md (nop_endbr): Don't check TARGET_IBT.
>   * config/i386/i386.opt (mcet): Update help message.
>   (mshstk): Likewise.
>   (mibt): Removed.
>   * doc/invoke.texi: Remove -mibt.  Document __CET__.  Document
>   -mcet as an alias for -mshstk.
> 
> gcc/testsuite/
> 
>   PR target/85469
>   * gcc.target/i386/pr85044.c (dg-options): Remove -mibt.
>   * gcc.target/i386/sse-26.c (dg-options): Remove -mno-ibt.
> ---
>  gcc/common/config/i386/i386-common.c| 17 -
>  gcc/config/i386/cet.h   |  6 +++---
>  gcc/config/i386/driver-i386.c   |  6 ++
>  gcc/config/i386/i386-c.c| 20 ++--
>  gcc/config/i386/i386.c  |  2 --
>  gcc/config/i386/i386.h  |  2 --
>  gcc/config/i386/i386.md |  2 +-
>  gcc/config/i386/i386.opt| 12 
>  gcc/doc/invoke.texi | 28 +++-
>  gcc/testsuite/gcc.target/i386/pr85044.c |  2 +-
>  gcc/testsuite/gcc.target/i386/sse-26.c  |  2 +-
>  11 files changed, 29 insertions(+), 70 deletions(-)
> 
> diff --git a/gcc/common/config/i386/i386-common.c
> b/gcc/common/config/i386/i386-common.c
> index 0bb2783cfab..74a3490f7a3 100644
> --- a/gcc/common/config/i386/i386-common.c
> +++ b/gcc/common/config/i386/i386-common.c
> @@ -147,7 +147,6 @@ along with GCC; see the file COPYING3.  If not see
>  #define OPTION_MASK_ISA_PKU_SET OPTION_MASK_ISA_PKU
>  #define OPTION_MASK_ISA_RDPID_SET OPTION_MASK_ISA_RDPID
>  #define OPTION_MASK_ISA_GFNI_SET OPTION_MASK_ISA_GFNI
> -#define OPTION_MASK_ISA_IBT_SET OPTION_MASK_ISA_IBT
>  #define OPTION_MASK_ISA_SHSTK_SET OPTION_MASK_ISA_SHSTK
>  #define OPTION_MASK_ISA_VAES_SET OPTION_MASK_ISA_VAES
>  #define OPTION_MASK_ISA_VPCLMULQDQ_SET
> OPTION_MASK_ISA_VPCLMULQDQ
> @@ -224,7 +223,6 @@ along with GCC; see the file COPYING3.  If not see
>  #define OPTION_MASK_ISA_PKU_UNSET OPTION_MASK_ISA_PKU
>  #define OPTION_MASK_ISA_RDPID_UNSET OPTION_MASK_ISA_RDPID
>  #define OPTION_MASK_ISA_GFNI_UNSET OPTION_MASK_I

RE: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Tsimbalist, Igor V]

> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Friday, April 20, 2018 3:17 AM
> To: Jakub Jelinek <ja...@redhat.com>
> Cc: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; Richard Biener
> <richard.guent...@gmail.com>; Uros Bizjak <ubiz...@gmail.com>; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs
> 
> On Thu, Apr 19, 2018 at 3:37 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> > On Thu, Apr 19, 2018 at 03:08:06PM -0700, H.J. Lu wrote:
> >> > As -fcf-protection and -mcet/-mibt/-mshstk are are disjoint and
> >> > control different parts I agree with
> >> >
> >> > +  if ((isa_flag & OPTION_MASK_ISA_SHSTK))
> >> > +def_or_undef (parse_in, "__SHSTK__");
> >> > +  if (flag_cf_protection != CF_NONE)
> >> > +def_or_undef (parse_in, "__CET__");
> >> >
> >> > Why __CET_IBT__ and __CET_SHSTK__ are needed? Moreover the
> naming is
> >> > confusing as 'IBT' and 'SHSTK' are related to HW features which are
> controlled
> >> > by -m options. __CET__ seems to be enough.
> >> >
> >>
> >> One needs to know if IBT and SHSTK are enabled by -fcf-protection.
> They will
> >> be checked by  and glibc.
> >
> > So can't you define __CET__ to 3 if CF_FULL, to 1 if CF_BRANCH and 2 if
> > CF_RETURN?  Then if code doesn't care which one it is, it can just #ifdef
> > __CET__, otherwise it can test which of those is enabled.
> > Implementation-wise it would probably need to be:
> >   if (flag_cf_protection != CF_NONE)
> > {
> >   if (def_or_undef == cpp_undef)
> > def_or_undef (parse_in, "__CET__");
> >   else if ((flag_cf_protection & CF_FULL) == CF_FULL)
> > def_or_undef (parse_in, "__CET__=3");
> >   else if (flag_cf_protection & CF_BRANCH)
> > def_or_undef (parse_in, "__CET__=1");
> >   else if (flag_cf_protection & CF_RETURN)
> > def_or_undef (parse_in, "__CET__=2");
> > }
> > or so.  Actually, because it doesn't depend on something that can change
> > depending on target attributes, it probably doesn't even belong in this
> > function, but to ix86_target_macros and there you can just cpp_define
> > it, don't deal with cpp_undef at all.
> 
> Something like this?

Shouldn't this

-# ifdef __IBT__
+# if (__CET__ & 1) != 0

Be as

-# ifdef __IBT__
+#ifdef __CET__
+# if (__CET__ & 1) != 0

OK otherwise.

Igor

> 
> --
> H.J.

RE: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Tsimbalist, Igor V]

> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Friday, April 20, 2018 12:08 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: Jakub Jelinek <ja...@redhat.com>; Richard Biener
> <richard.guent...@gmail.com>; Uros Bizjak <ubiz...@gmail.com>; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs
> 
> On Thu, Apr 19, 2018 at 2:18 PM, Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com> wrote:
> >> -Original Message-
> >> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> >> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> >> Sent: Thursday, April 19, 2018 10:02 PM
> >> To: Jakub Jelinek <ja...@redhat.com>
> >> Cc: Richard Biener <richard.guent...@gmail.com>; Uros Bizjak
> >> <ubiz...@gmail.com>; gcc-patches@gcc.gnu.org; Tsimbalist, Igor V
> >> <igor.v.tsimbal...@intel.com>
> >> Subject: Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs
> >>
> >> On Thu, Apr 19, 2018 at 12:25 PM, Jakub Jelinek <ja...@redhat.com>
> >> wrote:
> >> > On Thu, Apr 19, 2018 at 06:30:37AM -0700, H.J. Lu wrote:
> >> >>   * config/i386/i386-c.c (ix86_target_macros_internal): Also
> >> >>   define __IBT__ and __SHSTK__ for -fcf-protection.
> >> >
> >> >> --- a/gcc/config/i386/i386-c.c
> >> >> +++ b/gcc/config/i386/i386-c.c
> >> >> @@ -499,13 +499,15 @@ ix86_target_macros_internal
> (HOST_WIDE_INT
> >> isa_flag,
> >> >>  def_or_undef (parse_in, "__RDPID__");
> >> >>if (isa_flag & OPTION_MASK_ISA_GFNI)
> >> >>  def_or_undef (parse_in, "__GFNI__");
> >> >> -  if (isa_flag2 & OPTION_MASK_ISA_IBT)
> >> >> +  if ((isa_flag2 & OPTION_MASK_ISA_IBT)
> >> >> +  || (flag_cf_protection & CF_BRANCH))
> >> >>  {
> >> >>def_or_undef (parse_in, "__IBT__");
> >> >>if (flag_cf_protection != CF_NONE)
> >> >>   def_or_undef (parse_in, "__CET__");
> >> >>  }
> >> >> -  if (isa_flag & OPTION_MASK_ISA_SHSTK)
> >> >> +  if ((isa_flag & OPTION_MASK_ISA_SHSTK)
> >> >> +  || (flag_cf_protection & CF_RETURN))
> >> >>  {
> >> >>def_or_undef (parse_in, "__SHSTK__");
> >> >>if (flag_cf_protection != CF_NONE)
> >> >>   def_or_undef (parse_in, "__CET__");
> >> >>  }
> >> >
> >> > This looks completely wrong to me.
> >> > 1) there is no way to find out through preprocessor macros if
> >> > -mibt or -mshstk was actually used or not, so e.g. if you
> >> > #include 
> >> > and compile with -fcf-protection -mno-cet, then
> >> > #ifndef __SHSTK__
> >> > #pragma GCC push_options
> >> > #pragma GCC target ("shstk")
> >> > #define __DISABLE_SHSTK__
> >> > #endif /* __SHSTK__ */
> >> > will not be done and thus the intrinsics will appear to be in
> >> > in the default target (-mno-cet)
> >> > 2) preexisting - __CET__ is predefined twice, it should be done only
> >> > once using a condition that covers all cases when the macro should be
> >> > defined
> >> >
> >> > Don't you want to just predefine __CET__ and not __IBT__/__SHSTK__
> >> > if -fcf-protection -mno-cet, to make it clear?
> >> >
> >>
> >> We are removing -mibt:
> >>
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85469
> >>
> >> How about this?
> >>
> >>
> >> diff --git a/gcc/config/i386/i386-c.c b/gcc/config/i386/i386-c.c
> >> index fa8b3682b0c..26c7641075d 100644
> >> --- a/gcc/config/i386/i386-c.c
> >> +++ b/gcc/config/i386/i386-c.c
> >> @@ -499,20 +499,14 @@ ix86_target_macros_internal (HOST_WIDE_INT
> >> isa_flag,
> >>  def_or_undef (parse_in, "__RDPID__");
> >>if (isa_flag & OPTION_MASK_ISA_GFNI)
> >>  def_or_undef (parse_in, "__GFNI__");
> >> -  if ((isa_flag2 & OPTION_MASK_ISA_IBT)
> >> -  || (flag_cf_protection & CF_BRANCH))
> >> -{
> >> -  def_or_undef (parse_in, "__IBT__");
> >> -  if (flag_cf_protection != CF_NONE)
> >&

RE: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Thursday, April 19, 2018 10:02 PM
> To: Jakub Jelinek <ja...@redhat.com>
> Cc: Richard Biener <richard.guent...@gmail.com>; Uros Bizjak
> <ubiz...@gmail.com>; gcc-patches@gcc.gnu.org; Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com>
> Subject: Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs
> 
> On Thu, Apr 19, 2018 at 12:25 PM, Jakub Jelinek <ja...@redhat.com>
> wrote:
> > On Thu, Apr 19, 2018 at 06:30:37AM -0700, H.J. Lu wrote:
> >>   * config/i386/i386-c.c (ix86_target_macros_internal): Also
> >>   define __IBT__ and __SHSTK__ for -fcf-protection.
> >
> >> --- a/gcc/config/i386/i386-c.c
> >> +++ b/gcc/config/i386/i386-c.c
> >> @@ -499,13 +499,15 @@ ix86_target_macros_internal (HOST_WIDE_INT
> isa_flag,
> >>  def_or_undef (parse_in, "__RDPID__");
> >>if (isa_flag & OPTION_MASK_ISA_GFNI)
> >>  def_or_undef (parse_in, "__GFNI__");
> >> -  if (isa_flag2 & OPTION_MASK_ISA_IBT)
> >> +  if ((isa_flag2 & OPTION_MASK_ISA_IBT)
> >> +  || (flag_cf_protection & CF_BRANCH))
> >>  {
> >>def_or_undef (parse_in, "__IBT__");
> >>if (flag_cf_protection != CF_NONE)
> >>   def_or_undef (parse_in, "__CET__");
> >>  }
> >> -  if (isa_flag & OPTION_MASK_ISA_SHSTK)
> >> +  if ((isa_flag & OPTION_MASK_ISA_SHSTK)
> >> +  || (flag_cf_protection & CF_RETURN))
> >>  {
> >>def_or_undef (parse_in, "__SHSTK__");
> >>if (flag_cf_protection != CF_NONE)
> >>   def_or_undef (parse_in, "__CET__");
> >>  }
> >
> > This looks completely wrong to me.
> > 1) there is no way to find out through preprocessor macros if
> > -mibt or -mshstk was actually used or not, so e.g. if you
> > #include 
> > and compile with -fcf-protection -mno-cet, then
> > #ifndef __SHSTK__
> > #pragma GCC push_options
> > #pragma GCC target ("shstk")
> > #define __DISABLE_SHSTK__
> > #endif /* __SHSTK__ */
> > will not be done and thus the intrinsics will appear to be in
> > in the default target (-mno-cet)
> > 2) preexisting - __CET__ is predefined twice, it should be done only
> > once using a condition that covers all cases when the macro should be
> > defined
> >
> > Don't you want to just predefine __CET__ and not __IBT__/__SHSTK__
> > if -fcf-protection -mno-cet, to make it clear?
> >
> 
> We are removing -mibt:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85469
> 
> How about this?
> 
> 
> diff --git a/gcc/config/i386/i386-c.c b/gcc/config/i386/i386-c.c
> index fa8b3682b0c..26c7641075d 100644
> --- a/gcc/config/i386/i386-c.c
> +++ b/gcc/config/i386/i386-c.c
> @@ -499,20 +499,14 @@ ix86_target_macros_internal (HOST_WIDE_INT
> isa_flag,
>  def_or_undef (parse_in, "__RDPID__");
>if (isa_flag & OPTION_MASK_ISA_GFNI)
>  def_or_undef (parse_in, "__GFNI__");
> -  if ((isa_flag2 & OPTION_MASK_ISA_IBT)
> -  || (flag_cf_protection & CF_BRANCH))
> -{
> -  def_or_undef (parse_in, "__IBT__");
> -  if (flag_cf_protection != CF_NONE)
> -  def_or_undef (parse_in, "__CET__");
> -}
> -  if ((isa_flag & OPTION_MASK_ISA_SHSTK)
> -  || (flag_cf_protection & CF_RETURN))
> -{
> -  def_or_undef (parse_in, "__SHSTK__");
> -  if (flag_cf_protection != CF_NONE)
> -  def_or_undef (parse_in, "__CET__");
> -}
> +  if ((isa_flag & OPTION_MASK_ISA_SHSTK))
> +def_or_undef (parse_in, "__SHSTK__");
> +  if (flag_cf_protection != CF_NONE)
> +def_or_undef (parse_in, "__CET__");
> +  if ((flag_cf_protection & CF_BRANCH))
> +def_or_undef (parse_in, "__CET_IBT__");
> +  if ((flag_cf_protection & CF_RETURN))
> +def_or_undef (parse_in, "__CET_SHSTK__");
>if (isa_flag2 & OPTION_MASK_ISA_VAES)
>  def_or_undef (parse_in, "__VAES__");
>if (isa_flag & OPTION_MASK_ISA_VPCLMULQDQ)
> 
> This adds __CET_IBT__ and __CET_SHSTK__.

As -fcf-protection and -mcet/-mibt/-mshstk are are disjoint and
control different parts I agree with

+  if ((isa_flag & OPTION_MASK_ISA_SHSTK))
+def_or_undef (parse_in, "__SHSTK__");
+  if (flag_cf_protection != CF_NONE)
+def_or_undef (parse_in, "__CET__");

Why __CET_IBT__ and __CET_SHSTK__ are needed? Moreover the naming is
confusing as 'IBT' and 'SHSTK' are related to HW features which are controlled
by -m options. __CET__ seems to be enough.

Igor

> 
> --
> H.J.

RE: PING: [PATCH] libgcc/CET: Skip signal frames when unwinding shadow stack

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Wednesday, April 18, 2018 3:21 PM
> To: GCC Patches 
> Cc: Uros Bizjak ; Jeff Law 
> Subject: PING: [PATCH] libgcc/CET: Skip signal frames when unwinding
> shadow stack
> 
> On Thu, Apr 12, 2018 at 12:43 PM, H.J. Lu  wrote:
> > On Wed, Apr 11, 2018 at 3:37 AM, H.J. Lu  wrote:
> >> When -fcf-protection -mcet is used, I got
> >>
> >> FAIL: g++.dg/eh/sighandle.C
> >>
> >> (gdb) bt
> >>  #0  _Unwind_RaiseException (exc=exc@entry=0x416ed0)
> >> at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:140
> >>  #1  0x77d9936b in __cxxabiv1::__cxa_throw (obj= out>,
> >> tinfo=0x403dd0 , dest=0x0)
> >> at /export/gnu/import/git/sources/gcc/libstdc++-
> v3/libsupc++/eh_throw.cc:90
> >>  #2  0x00401255 in sighandler (signo=11, si=0x7fffd6f8,
> >> uc=0x7fffd5c0)
> >> at
> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/eh/sighandle.C:9
> >>  #3    Signal frame which isn't on shadow
> stack
> >>  #4  dosegv ()
> >> at
> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/eh/sighandle.C:14
> >>  #5  0x004012e3 in main ()
> >> at
> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/eh/sighandle.C:30
> >> (gdb) p frames
> >> $6 = 5
> >> (gdb)
> >>
> >> frame count should be 4, not 5.  This patch skips signal frames when
> >> unwinding shadow stack.
> >>
> >> Tested on i686 and x86-64.  OK for trunk?
> >>
> >> H.J.
> >> 
> >> PR libgcc/85334
> >> * unwind-generic.h (_Unwind_Frames_Increment): New.
> >> * config/i386/shadow-stack-unwind.h (_Unwind_Frames_Increment):
> >> Likewise.
> >> * unwind.inc (_Unwind_RaiseException_Phase2): Increment frame
> >> count with _Unwind_Frames_Increment.
> >> (_Unwind_ForcedUnwind_Phase2): Likewise.
> 
> >
> > I need to increment frame count after uw_advance_context which will set
> > the signal frame bit.
> >
> > OK for trunk?
> 
> PING:

OK.

Igor

> https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00633.html
> 
> 
> --
> H.J.

RE: [PATCH] i386: Add save_stack_nonlocal and restore_stack_nonlocal

[Tsimbalist, Igor V]

> -Original Message-
> From: Lu, Hongjiu
> Sent: Sunday, April 15, 2018 12:58 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Uros Bizjak <ubiz...@gmail.com>; Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com>
> Subject: [PATCH] i386: Add save_stack_nonlocal and restore_stack_nonlocal
> 
> Define STACK_SAVEAREA_MODE to hold both shadow stack and stack
> pointers.
> Replace builtin_setjmp_setup and builtin_longjmp with save_stack_nonlocal
> and restore_stack_nonlocal to support both builtin setjmp/longjmp as well
> as non-local goto in nested functions.
> 
> OK for trunk?

OK.

Igor

> H.J.
> 
> gcc/
> 
>   PR target/85397
>   * config/i386/i386.h (STACK_SAVEAREA_MODE): New.
>   * config/i386/i386.md (builtin_setjmp_setup): Removed.
>   (builtin_longjmp): Likewise.
>   (save_stack_nonlocal): New pattern.
>   (restore_stack_nonlocal): Likewise.
> 
> gcc/testsuite/
> 
>   PR target/85397
>   * gcc.dg/torture/pr85397-1.c: New test.
>   * gcc.target/i386/cet-sjlj-6a.c: Adjusted.
>   * gcc.target/i386/cet-sjlj-6b.c: Likewise.
> ---
>  gcc/config/i386/i386.h  |  11 +++
>  gcc/config/i386/i386.md | 107 +---
> 
>  gcc/testsuite/gcc.dg/torture/pr85397-1.c|  29 
>  gcc/testsuite/gcc.target/i386/cet-sjlj-6a.c |   4 +-
>  gcc/testsuite/gcc.target/i386/cet-sjlj-6b.c |   4 +-
>  5 files changed, 92 insertions(+), 63 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr85397-1.c
> 
> diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> index c7f9b4551b3..c45d22cae98 100644
> --- a/gcc/config/i386/i386.h
> +++ b/gcc/config/i386/i386.h
> @@ -1943,6 +1943,17 @@ do {
>   \
> between pointers and any other objects of this machine mode.  */
>  #define Pmode (ix86_pmode == PMODE_DI ? DImode : SImode)
> 
> +/* Supply a definition of STACK_SAVEAREA_MODE for emit_stack_save.
> +   NONLOCAL needs space to save both shadow stack and stack pointers.
> +
> +   FIXME: We only need to save and restore stack pointer in ptr_mode.
> +   But expand_builtin_setjmp_setup and expand_builtin_longjmp use Pmode
> +   to save and restore stack pointer.  See
> +   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84150
> + */
> +#define STACK_SAVEAREA_MODE(LEVEL)   \
> +  ((LEVEL) == SAVE_NONLOCAL ? (TARGET_64BIT ? TImode : DImode) :
> Pmode)
> +
>  /* Specify the machine mode that bounds have.  */
>  #define BNDmode (ix86_pmode == PMODE_DI ? BND64mode :
> BND32mode)
> 
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 352212094ec..841d0a77ecc 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -18485,29 +18485,6 @@
>"* return output_probe_stack_range (operands[0], operands[2]);"
>[(set_attr "type" "multi")])
> 
> -/* Additional processing for builtin_setjmp.  Store the shadow stack pointer
> -   as a forth element in jmpbuf.  */
> -(define_expand "builtin_setjmp_setup"
> -  [(match_operand 0 "address_operand")]
> -  "TARGET_SHSTK"
> -{
> -  if (flag_cf_protection & CF_RETURN)
> -{
> -  rtx mem, reg_ssp;
> -
> -  mem = gen_rtx_MEM (word_mode,
> -  plus_constant (Pmode, operands[0],
> - 3 * GET_MODE_SIZE (ptr_mode)));
> -  reg_ssp = gen_reg_rtx (word_mode);
> -  emit_insn (gen_rtx_SET (reg_ssp, const0_rtx));
> -  emit_insn ((word_mode == SImode)
> -  ? gen_rdsspsi (reg_ssp)
> -  : gen_rdsspdi (reg_ssp));
> -  emit_move_insn (mem, reg_ssp);
> -}
> -  DONE;
> -})
> -
>  (define_expand "builtin_setjmp_receiver"
>[(label_ref (match_operand 0))]
>"!TARGET_64BIT && flag_pic"
> @@ -18528,19 +18505,46 @@
>DONE;
>  })
> 
> -(define_expand "builtin_longjmp"
> -  [(match_operand 0 "address_operand")]
> -  "TARGET_SHSTK"
> +(define_expand "save_stack_nonlocal"
> +  [(set (match_operand 0 "memory_operand")
> +(match_operand 1 "register_operand"))]
> +  ""
>  {
> -  rtx fp, lab, stack;
> -  rtx flags, jump, noadj_label, inc_label, loop_label;
> -  rtx reg_adj, reg_ssp, mem_buf, tmp, clob;
> -  machine_mode sa_mode = STACK_SAVEAREA_MODE (SAVE_NONLOCAL);
> +  rtx stack_slot;
> +  if (TARGET_SHSTK && (flag_cf_protection & CF_RETURN))
> +{
> +  /* Copy shadow stack pointer to the first slot and stack ppointer
> +  to the second slot.  */
> +  rtx ssp_slot = 

RE: [PATCH] x86/cet: Properly output labels in property note section

[Tsimbalist, Igor V]

> -Original Message-
> From: Lu, Hongjiu
> Sent: Sunday, April 15, 2018 1:06 PM
> To: gcc-patches@gcc.gnu.org; Uros Bizjak <ubiz...@gmail.com>; Tsimbalist,
> Igor V <igor.v.tsimbal...@intel.com>
> Subject: [PATCH] x86/cet: Properly output labels in property note section
> 
> Replace ASM_OUTPUT_LABEL with fprintf so that internal labels in property
> note section are unchanged -fleading-underscore.
> 
> OK for trunk?

OK.

Igor

> H.J.
> ---
> gcc/
> 
>   PR target/85404
>   * config/i386/cet.c (file_end_indicate_exec_stack_and_cet):
>   Replace ASM_OUTPUT_LABEL with fprintf.
> 
> gcc/testsuite/
> 
>   PR target/85404
>   * gcc.target/i386/pr85404.c: New test.
> ---
>  gcc/config/i386/cet.c   | 10 +-
>  gcc/testsuite/gcc.target/i386/pr85404.c |  6 ++
>  2 files changed, 11 insertions(+), 5 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr85404.c
> 
> diff --git a/gcc/config/i386/cet.c b/gcc/config/i386/cet.c
> index 4a1e013fdde..d5bbe8b7fe8 100644
> --- a/gcc/config/i386/cet.c
> +++ b/gcc/config/i386/cet.c
> @@ -57,20 +57,20 @@ file_end_indicate_exec_stack_and_cet (void)
>fprintf (asm_out_file, ASM_LONG " 4f - 1f\n");
>/* note type: NT_GNU_PROPERTY_TYPE_0.  */
>fprintf (asm_out_file, ASM_LONG " 5\n");
> -  ASM_OUTPUT_LABEL (asm_out_file, "0");
> +  fprintf (asm_out_file, "0:\n");
>/* vendor name: "GNU".  */
>fprintf (asm_out_file, STRING_ASM_OP " \"GNU\"\n");
> -  ASM_OUTPUT_LABEL (asm_out_file, "1");
> +  fprintf (asm_out_file, "1:\n");
>ASM_OUTPUT_ALIGN (asm_out_file, p2align);
>/* pr_type: GNU_PROPERTY_X86_FEATURE_1_AND.  */
>fprintf (asm_out_file, ASM_LONG " 0xc002\n");
>/* pr_datasz.  */\
>fprintf (asm_out_file, ASM_LONG " 3f - 2f\n");
> -  ASM_OUTPUT_LABEL (asm_out_file, "2");
> +  fprintf (asm_out_file, "2:\n");
>/* GNU_PROPERTY_X86_FEATURE_1_XXX.  */
>fprintf (asm_out_file, ASM_LONG " 0x%x\n", feature_1);
> -  ASM_OUTPUT_LABEL (asm_out_file, "3");
> +  fprintf (asm_out_file, "3:\n");
>ASM_OUTPUT_ALIGN (asm_out_file, p2align);
> -  ASM_OUTPUT_LABEL (asm_out_file, "4");
> +  fprintf (asm_out_file, "4:\n");
>  }
>  }
> diff --git a/gcc/testsuite/gcc.target/i386/pr85404.c
> b/gcc/testsuite/gcc.target/i386/pr85404.c
> new file mode 100644
> index 000..bbf456ec024
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr85404.c
> @@ -0,0 +1,6 @@
> +/* { dg-do assemble } */
> +/* { dg-options "-fleading-underscore -mcet -fcf-protection" } */
> +
> +void func(void) __asm("_func");
> +void _func(int x) {}
> +void func(void) {}
> --
> 2.14.3

RE: PING: [PATCH] libgcc/CET: Add _CET_ENDBR to __stack_split_initialize

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Wednesday, April 18, 2018 3:22 PM
> To: GCC Patches 
> Cc: Uros Bizjak 
> Subject: PING: [PATCH] libgcc/CET: Add _CET_ENDBR to __stack_split_initialize
> 
> On Thu, Apr 12, 2018 at 6:21 AM, H.J. Lu  wrote:
> > Program received signal SIGSEGV, Segmentation fault.
> > __stack_split_initialize ()
> > at
> /export/gnu/import/git/sources/gcc/libgcc/config/i386/morestack.S:751
> > 751 leaq-16000(%rsp),%rax   # We should have at least 
> > 16K.
> > Missing separate debuginfos, use: dnf debuginfo-install libgcc-8.0.1-
> 0.21.0.fc28.x86_64
> > (gdb) disass
> > Dump of assembler code for function __stack_split_initialize:
> > => 0x00402858 <+0>: lea-0x3e80(%rsp),%rax
> >0x00402860 <+8>: mov%rax,%fs:0x70
> >0x00402869 <+17>:sub$0x8,%rsp
> >0x0040286d <+21>:mov%rsp,%rdi
> >0x00402870 <+24>:mov$0x3e80,%esi
> >0x00402875 <+29>:callq  0x401810
> <__generic_morestack_set_initial_sp>
> >0x0040287a <+34>:add$0x8,%rsp
> >0x0040287e <+38>:retq
> > End of assembler dump.
> > (gdb)
> >
> > This patch adds the missing ENDBR to __stack_split_initialize.
> >
> > OK for trunk?
> >
> > H.J.
> > ---
> > PR libgcc/85379
> > * config/i386/morestack.S (__stack_split_initialize): Add
> > _CET_ENDBR.
> > ---
> >  libgcc/config/i386/morestack.S | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libgcc/config/i386/morestack.S
> b/libgcc/config/i386/morestack.S
> > index eca441a2867..99e65eaaff4 100644
> > --- a/libgcc/config/i386/morestack.S
> > +++ b/libgcc/config/i386/morestack.S
> > @@ -730,6 +730,7 @@ __morestack_large_model:
> >  #endif
> >
> >  __stack_split_initialize:
> > +   _CET_ENDBR
> >
> >  #ifndef __x86_64__
> >
> > --
> > 2.14.3
> >
> 
> PING.

OK.

Igor

> --
> H.J.

RE: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Tsimbalist, Igor V]

> -Original Message-
> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> Sent: Thursday, April 19, 2018 3:36 PM
> To: H.J. Lu <hjl.to...@gmail.com>
> Cc: Richard Biener <richard.guent...@gmail.com>; gcc-
> patc...@gcc.gnu.org; Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Subject: Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs
> 
> On Thu, Apr 19, 2018 at 3:30 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> > On Wed, Apr 18, 2018 at 01:35:33PM +0200, Richard Biener wrote:
> >> On Wed, Apr 18, 2018 at 1:24 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> >> > On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu <hjl.to...@gmail.com>
> wrote:
> >> >> On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu <hjl.to...@gmail.com>
> wrote:
> >> >>> On Tue, Apr 17, 2018 at 12:03 PM, H.J. Lu <hjl.to...@gmail.com>
> wrote:
> >> >>>> On Tue, Apr 17, 2018 at 11:55 AM, Uros Bizjak
> <ubiz...@gmail.com> wrote:
> >> >>>>> On Tue, Apr 17, 2018 at 8:42 PM, H.J. Lu
> <hongjiu...@intel.com> wrote:
> >> >>>>>> -fcf-protection -mcet can't be used with IFUNC features, like
> symbol
> >> >>>>>> multiversioning or target clone, since IBT/SHSTK are applied to
> the whole
> >> >>>>>> program and they may be disabled in some functions.  But -
> fcf-protection
> >> >>>>>> is implemented with multi-byte NOPs on all 64-bit processors
> as well as
> >> >>>>>> 32-bit processors starting with Pentium Pro.  If -fcf-protection
> requires
> >> >>>>>> -mcet, IFUNC features can't be used on Linux when -fcf-
> protection is
> >> >>>>>> enabled by default.
> >> >>>>>>
> >> >>>>>> This patch changes -fcf-protection to to enable the NOP
> portion of CET
> >> >>>>>> ISAs unless IBT and/or SHSTK are disabled explicitly.  The rest of
> CET
> >> >>>>>> ISAs, including intrinsics, still requires -mcet, -mibt or -mshstk.
> >> >>>>>>
> >> >>>>>> OK for trunk?
> >> >>>>>
> >> >>>>> As said in the PR, NOP sequences have non-zero cost in the
> executable
> >> >>>>> (they enlarge the executable), so I don't think this feature should
> be
> >> >>>>> enabled by default.
> >> >>>>>
> >> >>>>> There is always a configure option if someone wants their
> compiler to
> >> >>>>> always emit relevant multi-byte nops.
> >> >>>>
> >> >>>> What we need is an option to enable -fcf-function with multi-byte
> NOPs
> >> >>>> without -mcet which enables the full CET ISAs.  A configure option
> >> >>>> without the corresponding the command-line option makes test
> and
> >> >>>> debug difficult.   I can add
> >> >>>>
> >> >>>> --enable-cf-function-nop or --with-cf-function-nop
> >> >>>>
> >> >>>> with
> >> >>>>
> >> >>>> -fct-function-nop
> >> >>>>
> >> >>>
> >> >>> How about adding -mno-cet, which enables the NOP portion of
> CET
> >> >>
> >> >> I meant -mnop-cet, not -mno-cet.
> >> >>
> >> >
> >> > Here is a patch to add -mnop and use it with -fcf-protection.
> >>
> >> +mnop
> >> +Target Report Var(flag_nop) Init(0)
> >> +Support multi-byte NOP code generation.
> >>
> >> the option name is incredibly bad and the documentation doesn't make it
> >> better either.  The invoke.texi docs refer to duplicate {-mcet}.
> >>
> >> Isn't there a -fcf-protection sub-set that can be used to automatically
> >> enable this?  Or simply do this mode by default when
> >> -fcf-protection is used but neither -mcet nor -mibt is enabled?
> >>
> >
> > Since multi-byte NOPs are used to implement -fcf-protection on x86, we
> > propose a new design for -fcf-protection:
> >
> > 1. -fcf-protection option will report the unsupported error on non-x86
> > platform. On x86 platform it's supported and inserts endbr-nop
> > instructions and properties, depending on its value (full/branch/return)
> > 2. -mcet/-mibt/-mshstk options control intrinsics only.
> > 3. These options are independent and do not influence each other so no
> > need for cross checking between them.
> >
> > OK for trunk?
> 
> This patch touches only CET related code, so Igor's OK should be enough.

I have reviewed the patch and I'm ok with it.

Igor

> Uros.

RE: PING: [PATCH] i386: Insert ENDBR after __morestack call

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Wednesday, April 18, 2018 3:25 PM
> To: GCC Patches <gcc-patches@gcc.gnu.org>; Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com>
> Cc: Uros Bizjak <ubiz...@gmail.com>
> Subject: PING: [PATCH] i386: Insert ENDBR after __morestack call
> 
> On Fri, Apr 13, 2018 at 5:56 AM, H.J. Lu <hongjiu...@intel.com> wrote:
> > Since __morestack will jump back to its callee via indirect call, we
> > need to insert ENDBR after calling __morestack.
> >
> > OK for trunk?
> >
> > H.J.
> > 
> > gcc/
> >
> > PR target/85388
> > * config/i386/i386.c (ix86_expand_split_stack_prologue): Insert
> > ENDBR after calling __morestack.
> >
> > gcc/testsuite/
> >
> > PR target/85388
> > * gcc.dg/pr85388-1.c: New test.
> > * gcc.dg/pr85388-2.c: Likewise.
> > * gcc.dg/pr85388-3.c: Likewise.
> > * gcc.dg/pr85388-4.c: Likewise.
> > * gcc.dg/pr85388-5.c: Likewise.
> > * gcc.dg/pr85388-6.c: Likewise.
> > ---
> >  gcc/config/i386/i386.c   | 11 ++-
> >  gcc/testsuite/gcc.dg/pr85388-1.c | 50
> +
> >  gcc/testsuite/gcc.dg/pr85388-2.c | 56
> 
> >  gcc/testsuite/gcc.dg/pr85388-3.c | 65
> +
> >  gcc/testsuite/gcc.dg/pr85388-4.c | 69
> 
> >  gcc/testsuite/gcc.dg/pr85388-5.c | 54
> +++
> >  gcc/testsuite/gcc.dg/pr85388-6.c | 56
> 
> >  7 files changed, 360 insertions(+), 1 deletion(-)
> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-1.c
> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-2.c
> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-3.c
> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-4.c
> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-5.c
> >  create mode 100644 gcc/testsuite/gcc.dg/pr85388-6.c
> >
> > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> > index 03e5c433574..8b4fd8ae30b 100644
> > --- a/gcc/config/i386/i386.c
> > +++ b/gcc/config/i386/i386.c
> > @@ -15242,7 +15242,16 @@ ix86_expand_split_stack_prologue (void)
> >   instruction--we need control flow to continue at the subsequent
> >   label.  Therefore, we use an unspec.  */
> >gcc_assert (crtl->args.pops_args < 65536);
> > -  emit_insn (gen_split_stack_return (GEN_INT (crtl->args.pops_args)));
> > +  rtx_insn *ret_insn
> > += emit_insn (gen_split_stack_return (GEN_INT (crtl->args.pops_args)));
> > +
> > +  if ((flag_cf_protection & CF_BRANCH) && TARGET_IBT)
> > +{
> > +  /* Insert ENDBR since __morestack will jump back here via indirect
> > +call.  */
> > +  rtx cet_eb = gen_nop_endbr ();
> > +  emit_insn_after (cet_eb, ret_insn);
> > +}
> >
> >/* If we are in 64-bit mode and this function uses a static chain,
> >   we saved %r10 in %rax before calling _morestack.  */
> 
> PING:
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00669.html
> 

OK.

Igor

> 
> --
> H.J.

RE: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek
> Sent: Wednesday, April 18, 2018 2:10 PM
> To: H.J. Lu <hjl.to...@gmail.com>
> Cc: Uros Bizjak <ubiz...@gmail.com>; Richard Biener
> <richard.guent...@gmail.com>; gcc-patches@gcc.gnu.org; Tsimbalist, Igor
> V <igor.v.tsimbal...@intel.com>
> Subject: Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs
> 
> On Wed, Apr 18, 2018 at 02:04:50PM +0200, Jakub Jelinek wrote:
> > On Wed, Apr 18, 2018 at 04:57:41AM -0700, H.J. Lu wrote:
> > > On Wed, Apr 18, 2018 at 4:55 AM, Uros Bizjak <ubiz...@gmail.com>
> wrote:
> > > > On Wed, Apr 18, 2018 at 1:39 PM, H.J. Lu <hjl.to...@gmail.com>
> wrote:
> > > >
> > > >>>> Here is a patch to add -mnop and use it with -fcf-protection.
> > > >>>
> > > >>> +mnop
> > > >>> +Target Report Var(flag_nop) Init(0)
> > > >>> +Support multi-byte NOP code generation.
> > > >>>
> > > >>> the option name is incredibly bad and the documentation doesn't
> make it
> > > >>> better either.  The invoke.texi docs refer to duplicate {-mcet}.
> > > >>>
> > > >>> Isn't there a -fcf-protection sub-set that can be used to
> automatically
> > > >>> enable this?  Or simply do this mode by default when
> > > >>> -fcf-protection is used but neither -mcet nor -mibt is enabled?
> > > >>
> > > >> Make -fcf-protection default to multi-byte NOPs works.  Uros,
> > > >> should I prepare a patch?
> > > >
> > > > Please make it an opt-in feature, so the compiler won't litter the
> > > > executable with unnecessary nops without user consent.
> > > >
> > >
> > > -fcf-protection is off by default.  Users need to pass -fcf-protection
> > > to enable it.  I will work on such a patch.
> >
> > That is not true.  When building gcc itself, config/cet.m4 makes
> > -fcf-protection -mcet the default if assembler supports it.
> > The request was to change --enable-cet configure option from having
> > yes,no,default arguments with default autodetection and being a default
> > if --enable-cet*/--disable-cet is not specified to say
> > yes,no,auto arguments where no would be the default and auto would be
> the
> > current default - enable it if as supports it, disable otherwise.
> 
> So untested patch would be something like:
> 
> 2018-04-18  Jakub Jelinek  <ja...@redhat.com>
> 
>   * config/cet.m4 (GCC_CET_FLAGS): Default to --disable-cet, replace
>   --enable-cet=default with --enable-cet=auto.
> 
>   * doc/install.texi: Document --disable-cet being the default and
>   --enable-cet=auto.
> 
> --- gcc/config/cet.m4.jj  2018-02-19 19:57:05.221280084 +0100
> +++ gcc/config/cet.m4 2018-04-18 14:05:31.514859185 +0200
> @@ -3,14 +3,14 @@ dnl GCC_CET_FLAGS
>  dnl(SHELL-CODE_HANDLER)
>  dnl
>  AC_DEFUN([GCC_CET_FLAGS],[dnl
> -GCC_ENABLE(cet, default, ,[enable Intel CET in target libraries],
> -permit yes|no|default)
> +GCC_ENABLE(cet, no, ,[enable Intel CET in target libraries],
> +permit yes|no|auto)
>  AC_MSG_CHECKING([for CET support])
> 
>  case "$host" in
>i[[34567]]86-*-linux* | x86_64-*-linux*)
>  case "$enable_cet" in
> -  default)
> +  auto)
>   # Check if target supports multi-byte NOPs
>   # and if assembler supports CET insn.
>   AC_COMPILE_IFELSE(
> --- gcc/doc/install.texi.jj   2018-02-08 12:21:20.791749480 +0100
> +++ gcc/doc/install.texi  2018-04-18 14:07:19.637901528 +0200
> @@ -2103,10 +2103,11 @@ instrumentation, see @option{-fcf-protec
>  to add @option{-fcf-protection} and, if needed, other target
>  specific options to a set of building options.
> 
> -The option is enabled by default on Linux/x86 if target binutils
> -supports @code{Intel CET} instructions.  In this case the target
> -libraries are configured to get additional @option{-fcf-protection}
> -and @option{-mcet} options.
> +The option is disabled by default on Linux/x86.  When
> +@code{--enable-cet=auto} is used, it is enabled if target binutils
> +supports @code{Intel CET} instructions and disabled otherwise.
> +In this case the target libraries are configured to get additional
> +@option{-fcf-protection} and @option{-mcet} options.
>  @end table
> 
>  @subheading Cross-Compiler-Specific Options
> 

Thanks! I will work on this.

>   Jakub

RE: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Wednesday, April 18, 2018 1:39 PM
> To: Richard Biener <richard.guent...@gmail.com>
> Cc: Uros Bizjak <ubiz...@gmail.com>; gcc-patches@gcc.gnu.org; Tsimbalist,
> Igor V <igor.v.tsimbal...@intel.com>
> Subject: Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs
> 
> On Wed, Apr 18, 2018 at 4:35 AM, Richard Biener
> <richard.guent...@gmail.com> wrote:
> > On Wed, Apr 18, 2018 at 1:24 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> >> On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> >>> On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu <hjl.to...@gmail.com>
> wrote:
> >>>> On Tue, Apr 17, 2018 at 12:03 PM, H.J. Lu <hjl.to...@gmail.com>
> wrote:
> >>>>> On Tue, Apr 17, 2018 at 11:55 AM, Uros Bizjak
> <ubiz...@gmail.com> wrote:
> >>>>>> On Tue, Apr 17, 2018 at 8:42 PM, H.J. Lu <hongjiu...@intel.com>
> wrote:
> >>>>>>> -fcf-protection -mcet can't be used with IFUNC features, like
> symbol
> >>>>>>> multiversioning or target clone, since IBT/SHSTK are applied to
> the whole
> >>>>>>> program and they may be disabled in some functions.  But -fcf-
> protection
> >>>>>>> is implemented with multi-byte NOPs on all 64-bit processors as
> well as
> >>>>>>> 32-bit processors starting with Pentium Pro.  If -fcf-protection
> requires
> >>>>>>> -mcet, IFUNC features can't be used on Linux when -fcf-
> protection is
> >>>>>>> enabled by default.
> >>>>>>>
> >>>>>>> This patch changes -fcf-protection to to enable the NOP portion
> of CET
> >>>>>>> ISAs unless IBT and/or SHSTK are disabled explicitly.  The rest of
> CET
> >>>>>>> ISAs, including intrinsics, still requires -mcet, -mibt or -mshstk.
> >>>>>>>
> >>>>>>> OK for trunk?
> >>>>>>
> >>>>>> As said in the PR, NOP sequences have non-zero cost in the
> executable
> >>>>>> (they enlarge the executable), so I don't think this feature should
> be
> >>>>>> enabled by default.
> >>>>>>
> >>>>>> There is always a configure option if someone wants their compiler
> to
> >>>>>> always emit relevant multi-byte nops.
> >>>>>
> >>>>> What we need is an option to enable -fcf-function with multi-byte
> NOPs
> >>>>> without -mcet which enables the full CET ISAs.  A configure option
> >>>>> without the corresponding the command-line option makes test and
> >>>>> debug difficult.   I can add
> >>>>>
> >>>>> --enable-cf-function-nop or --with-cf-function-nop
> >>>>>
> >>>>> with
> >>>>>
> >>>>> -fct-function-nop
> >>>>>
> >>>>
> >>>> How about adding -mno-cet, which enables the NOP portion of CET
> >>>
> >>> I meant -mnop-cet, not -mno-cet.
> >>>
> >>
> >> Here is a patch to add -mnop and use it with -fcf-protection.
> >
> > +mnop
> > +Target Report Var(flag_nop) Init(0)
> > +Support multi-byte NOP code generation.
> >
> > the option name is incredibly bad and the documentation doesn't make it
> > better either.  The invoke.texi docs refer to duplicate {-mcet}.
> >
> > Isn't there a -fcf-protection sub-set that can be used to automatically
> > enable this?  Or simply do this mode by default when
> > -fcf-protection is used but neither -mcet nor -mibt is enabled?
> 
> Make -fcf-protection default to multi-byte NOPs works.  Uros,
> should I prepare a patch?

This is going to change the designed approach and has to be communicated 
to/agreed
with other compilers. And I assume there will be no extra option introduced, 
like -mnop.

Igor

> --
> H.J.

RE: [PATCH] x86: Compile with -fcf-protection=none -mno-cet

[Tsimbalist, Igor V]

> -Original Message-
> From: Lu, Hongjiu
> Sent: Sunday, April 15, 2018 12:59 PM
> To: gcc-patches@gcc.gnu.org; Uros Bizjak <ubiz...@gmail.com>; Tsimbalist,
> Igor V <igor.v.tsimbal...@intel.com>
> Subject: [PATCH] x86: Compile with -fcf-protection=none -mno-cet
> 
> These tests must be compiled with -fcf-protection=none -mno-cet.

Why -mno-cet is needed? -fcf-protection=none should not require any extra 
options.

Igor

> OK for trunk?
> 
> H.J.
> 
>   * c-c++-common/attr-nocf-check-1.c: Compile with
>   -fcf-protection=none -mno-cet for x86 targets.
>   * c-c++-common/attr-nocf-check-3.c: Likewise.
>   * gcc.dg/march-generic.c: Likewise.
>   * gcc.target/i386/align-limit.c: Likewise.
>   * gcc.target/i386/indirect-thunk-attr-7.c: Likewise.
>   * gcc.target/i386/indirect-thunk-extern-7.c: Likewise.
>   * gcc.target/i386/ret-thunk-26.c: Likewise.
> ---
>  gcc/testsuite/c-c++-common/attr-nocf-check-1.c  | 1 +
>  gcc/testsuite/c-c++-common/attr-nocf-check-3.c  | 1 +
>  gcc/testsuite/gcc.dg/march-generic.c| 2 +-
>  gcc/testsuite/gcc.target/i386/align-limit.c | 2 +-
>  gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c   | 2 +-
>  gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c | 2 +-
>  gcc/testsuite/gcc.target/i386/ret-thunk-26.c| 2 +-
>  7 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/gcc/testsuite/c-c++-common/attr-nocf-check-1.c
> b/gcc/testsuite/c-c++-common/attr-nocf-check-1.c
> index 15f69731b91..4d579136b5a 100644
> --- a/gcc/testsuite/c-c++-common/attr-nocf-check-1.c
> +++ b/gcc/testsuite/c-c++-common/attr-nocf-check-1.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-additional-options "-fcf-protection=none -mno-cet" { target i?86-*-
> * x86_64-*-* } } */
> 
>  int func (int) __attribute__ ((nocf_check)); /* { dg-warning "'nocf_check'
> attribute ignored" } */
>  int (*fptr) (int) __attribute__ ((nocf_check)); /* { dg-warning "'nocf_check'
> attribute ignored" } */
> diff --git a/gcc/testsuite/c-c++-common/attr-nocf-check-3.c
> b/gcc/testsuite/c-c++-common/attr-nocf-check-3.c
> index ad1ca7eec9b..da58d560a31 100644
> --- a/gcc/testsuite/c-c++-common/attr-nocf-check-3.c
> +++ b/gcc/testsuite/c-c++-common/attr-nocf-check-3.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-additional-options "-fcf-protection=none -mno-cet" { target i?86-*-
> * x86_64-*-* } } */
> 
>  int  foo (void) __attribute__ ((nocf_check)); /* { dg-warning "'nocf_check'
> attribute ignored" } */
>  void (*foo1) (void) __attribute__((nocf_check)); /* { dg-warning 
> "'nocf_check'
> attribute ignored" } */
> diff --git a/gcc/testsuite/gcc.dg/march-generic.c
> b/gcc/testsuite/gcc.dg/march-generic.c
> index fb5b83c7d74..94237fee0ca 100644
> --- a/gcc/testsuite/gcc.dg/march-generic.c
> +++ b/gcc/testsuite/gcc.dg/march-generic.c
> @@ -1,6 +1,6 @@
>  /* { dg-do compile { target i?86-*-* x86_64-*-* } } */
>  /* { dg-skip-if "" { *-*-* } { "-march=*" } { "" } } */
> -/* { dg-options "-march=generic" } */
> +/* { dg-options "-march=generic -fcf-protection=none -mno-cet" } */
>  /* { dg-error "'generic' CPU can be used only for '-mtune=' switch" "" {
> target *-*-* } 0 } */
>  /* { dg-bogus "march" "" { target *-*-* } 0 } */
>  int i;
> diff --git a/gcc/testsuite/gcc.target/i386/align-limit.c
> b/gcc/testsuite/gcc.target/i386/align-limit.c
> index d3d8dc5656e..2560e7b242f 100644
> --- a/gcc/testsuite/gcc.target/i386/align-limit.c
> +++ b/gcc/testsuite/gcc.target/i386/align-limit.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O2 -falign-functions=64 -flimit-function-alignment -
> march=amdfam10" } */
> +/* { dg-options "-O2 -falign-functions=64 -flimit-function-alignment -
> march=amdfam10 -fcf-protection=none -mno-cet" } */
>  /* { dg-final { scan-assembler ".p2align 6,,1" } } */
>  /* { dg-final { scan-assembler-not ".p2align 6,,63" } } */
> 
> diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c
> b/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c
> index d53fc887dcc..64c2ff66692 100644
> --- a/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c
> +++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-
> return=keep -fno-pic" } */
> +/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-
> return=keep -fno-pic -fcf-protecti

RE: [PATCH] i386: Insert ENDBR to trampoline for -fcf-protection=branch -mibt

[Tsimbalist, Igor V]

> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Monday, March 26, 2018 5:59 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: gcc-patches@gcc.gnu.org; Uros Bizjak <ubiz...@gmail.com>
> Subject: Re: [PATCH] i386: Insert ENDBR to trampoline for -fcf-
> protection=branch -mibt
> 
> On Mon, Mar 26, 2018 at 8:23 AM, Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com> wrote:
> >> -Original Message-
> >> From: Lu, Hongjiu
> >> Sent: Sunday, March 25, 2018 12:50 AM
> >> To: gcc-patches@gcc.gnu.org; Uros Bizjak <ubiz...@gmail.com>;
> Tsimbalist,
> >> Igor V <igor.v.tsimbal...@intel.com>
> >> Subject: [PATCH] i386: Insert ENDBR to trampoline for -fcf-
> >> protection=branch -mibt
> >>
> >> When -fcf-protection=branch -mibt are used, we need to insert ENDBR
> >> to trampoline.  TRAMPOLINE_SIZE is creased by 4 bytes to accommodate
> >> 4-byte ENDBR instruction.
> >>
> >> OK for trunk?
> >
> > Regarding the test. Is it possible to check what is generated in a
> trampoline? In particular, that endbr is generated.
> >
> 
> I think run-time test is sufficient.

Ok then.

> --
> H.J.

RE: [PATCH] i386: Insert ENDBR to trampoline for -fcf-protection=branch -mibt

[Tsimbalist, Igor V]

> -Original Message-
> From: Lu, Hongjiu
> Sent: Sunday, March 25, 2018 12:50 AM
> To: gcc-patches@gcc.gnu.org; Uros Bizjak <ubiz...@gmail.com>; Tsimbalist,
> Igor V <igor.v.tsimbal...@intel.com>
> Subject: [PATCH] i386: Insert ENDBR to trampoline for -fcf-
> protection=branch -mibt
> 
> When -fcf-protection=branch -mibt are used, we need to insert ENDBR
> to trampoline.  TRAMPOLINE_SIZE is creased by 4 bytes to accommodate
> 4-byte ENDBR instruction.
> 
> OK for trunk?

Regarding the test. Is it possible to check what is generated in a trampoline? 
In particular, that endbr is generated.

Igor

> H.J.
> 
> gcc/
> 
>   PR target/85044
>   * config/i386/i386.c (ix86_trampoline_init): Insert ENDBR for
>   -fcf-protection=branch -mibt.
>   * config/i386/i386.h (TRAMPOLINE_SIZE): Increased by 4 bytes.
> 
> gcc/testsuite/
> 
>   PR target/85044
>   * gcc.target/i386/pr85044.c: New test.
> ---
>  gcc/config/i386/i386.c  | 17 +
>  gcc/config/i386/i386.h  |  2 +-
>  gcc/testsuite/gcc.target/i386/pr85044.c | 24
> 
>  3 files changed, 42 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr85044.c
> 
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 3b264318f50..b4f6aec1434 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -30411,6 +30411,7 @@ ix86_trampoline_init (rtx m_tramp, tree fndecl,
> rtx chain_value)
>rtx mem, fnaddr;
>int opcode;
>int offset = 0;
> +  bool need_endbr = (flag_cf_protection & CF_BRANCH) && TARGET_IBT;
> 
>fnaddr = XEXP (DECL_RTL (fndecl), 0);
> 
> @@ -30418,6 +30419,14 @@ ix86_trampoline_init (rtx m_tramp, tree fndecl,
> rtx chain_value)
>  {
>int size;
> 
> +  if (need_endbr)
> + {
> +   /* Insert ENDBR64.  */
> +   mem = adjust_address (m_tramp, SImode, offset);
> +   emit_move_insn (mem, gen_int_mode (0xfa1e0ff3, SImode));
> +   offset += 4;
> + }
> +
>/* Load the function address to r11.  Try to load address using
>the shorter movl instead of movabs.  We may want to support
>movq for kernel mode, but kernel does not use trampolines at
> @@ -30495,6 +30504,14 @@ ix86_trampoline_init (rtx m_tramp, tree fndecl,
> rtx chain_value)
>else
>   opcode = 0x68;
> 
> +  if (need_endbr)
> + {
> +   /* Insert ENDBR32.  */
> +   mem = adjust_address (m_tramp, SImode, offset);
> +   emit_move_insn (mem, gen_int_mode (0xfb1e0ff3, SImode));
> +   offset += 4;
> + }
> +
>mem = adjust_address (m_tramp, QImode, offset);
>emit_move_insn (mem, gen_int_mode (opcode, QImode));
> 
> diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> index 7f4b04f421d..c7f9b4551b3 100644
> --- a/gcc/config/i386/i386.h
> +++ b/gcc/config/i386/i386.h
> @@ -1716,7 +1716,7 @@ typedef struct ix86_args {
> 
>  /* Length in units of the trampoline for entering a nested function.  */
> 
> -#define TRAMPOLINE_SIZE (TARGET_64BIT ? 24 : 10)
> +#define TRAMPOLINE_SIZE (TARGET_64BIT ? 28 : 14)
>  

>  /* Definitions for register eliminations.
> 
> diff --git a/gcc/testsuite/gcc.target/i386/pr85044.c
> b/gcc/testsuite/gcc.target/i386/pr85044.c
> new file mode 100644
> index 000..332f582d79b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr85044.c
> @@ -0,0 +1,24 @@
> +/* { dg-do run { target cet } } */
> +/* { dg-options "-O2 -fcf-protection=branch -mibt" } */
> +
> +void callme (void (*callback) (void));
> +
> +int
> +main (void)
> +{
> +  int ok = 0;
> +  void callback (void) { ok = 1; }
> +
> +  callme ();
> +
> +  if (!ok)
> +   __builtin_abort ();
> +  return 0;
> +}
> +
> +__attribute__((noinline, noclone))
> +void
> +callme (void (*callback) (void))
> +{
> +  (*callback) ();
> +}
> --
> 2.14.3

[PATCH] PR 85025: libgcc/config/i386/shadow-stack-unwind.h is wrong

[Tsimbalist, Igor V]

The incspp instruction from CET accepts only the value in the range of 0-255.
The patch fixes the typo in the loop to handle this.

I'm checking in the fix as obvious.

Thanks,
Igor

   PR target/85025
   * config/i386/shadow-stack-unwind.h: Fix a typo, tmp => 255.

Index: libgcc/config/i386/shadow-stack-unwind.h
===
--- libgcc/config/i386/shadow-stack-unwind.h(revision 258760)
+++ libgcc/config/i386/shadow-stack-unwind.h(working copy)
@@ -42,7 +42,7 @@
  _Unwind_Word tmp = (x);   \
  while (tmp > 255) \
{   \
- _inc_ssp (tmp);   \
+ _inc_ssp (255);   \
  tmp -= 255;   \
}   \
  _inc_ssp (tmp);   \

Igor

RE: PR84239, Reimplement CET intrinsics for rdssp/incssp insn

[Tsimbalist, Igor V]

Igor


> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Thursday, February 15, 2018 1:24 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: Sandra Loosemore <san...@codesourcery.com>; gcc-
> patc...@gcc.gnu.org; Uros Bizjak <ubiz...@gmail.com>
> Subject: RE: PR84239, Reimplement CET intrinsics for rdssp/incssp insn
> 
> This patch has broken bootstrap of a cross toolchain for x86_64 (the case
> where inhibit_libc is defined because there is no libc for the target
> available at that stage in the bootstrap process).
> 
> In file included from
> /scratch/jmyers/glibc-bot/build/compilers/x86_64-linux-gnu/gcc-
> first/gcc/include/xmmintrin.h:34,
>  from
> /scratch/jmyers/glibc-bot/build/compilers/x86_64-linux-gnu/gcc-
> first/gcc/include/x86intrin.h:33,
>  from
> /scratch/jmyers/glibc-bot/src/gcc/libgcc/config/i386/shadow-stack-
> unwind.h:25,
>  from ./md-unwind-support.h:27,
>  from 
> /scratch/jmyers/glibc-bot/src/gcc/libgcc/unwind-dw2.c:411:
> ../../.././gcc/mm_malloc.h:27:10: fatal error: stdlib.h: No such file or 
> directory
>  #include 
>   ^~
> 
> https://sourceware.org/ml/libc-testresults/2018-q1/msg00307.html
> 
> The patch makes shadow-stack-unwind.h include , which ends
> up
> including , which includes  and 
> unconditionally.  You can't include any libc system headers
> unconditionally from libgcc (only when inhibit_libc is not defined - and
> , being an installed header, can't test inhibit_libc because
> it's in the user's namespace).  So I think you need to avoid the
> mm_malloc.h include here somehow (without adding any inhibit_libc
> conditionals to installed headers).

Here is a proposed patch

diff --git a/libgcc/config/i386/shadow-stack-unwind.h 
b/libgcc/config/i386/shadow-stack-unwind.h
index 416e061..b7c3d98 100644
--- a/libgcc/config/i386/shadow-stack-unwind.h
+++ b/libgcc/config/i386/shadow-stack-unwind.h
@@ -22,7 +22,14 @@ a copy of the GCC Runtime Library Exception along with this 
program;
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 <http://www.gnu.org/licenses/>.  */

-#include 
+/* NB: We need _get_ssp and _inc_ssp from .  But we can't
+   include  which ends up including , which
+   includes  and  unconditionally.  But we can't
+   include any libc system headers unconditionally from libgcc.  Avoid
+   including  here by defining _IMMINTRIN_H_INCLUDED.  */
+#define _IMMINTRIN_H_INCLUDED
+#include 
+#undef _IMMINTRIN_H_INCLUDED

 /* Unwind the shadow stack for EH.  */
 #undef _Unwind_Frames_Extra

I haven't managed to run it through 
./glibc/glibc.sourceware/scripts/build-many-glibcs.py. I did bootstrap and CET 
tests.

Ok for trunk?

Igor

> --
> Joseph S. Myers
> jos...@codesourcery.com

[PATCH] MPX and CET changes in release notes

[Tsimbalist, Igor V]

MPX is going to be deprecated in gcc-8. Control-flow protection support is in 
gcc-8.
Reflect these in Release Notes for gcc-8.

Ok for trunk?

Igor


Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.36
diff -r1.36 changes.html
34a35,38
>   
> The MPX extensions to the C and C++ languages have been deprecated and
> will be removed in a future release.
>   
43a48,56
>   
> A new option -fcf-protection=[full|branch|return|none] is
> introduced to perform a code instrumentation to increase program security 
> by
> checking that target addresses of control-flow transfer instructions 
> (such as
> indirect function call, function return, indirect jump) are valid. 
> Currently
> the instrumentation is supported on x86 GNU/Linux target only. See, the 
> user
> guide for further information about the option syntax and section "New 
> Targets
> and Target Specific Improvements" for IA-32/x86-64 for more details.
>   
402a416,421
>   
> GCC now supports the Intel Control-flow Enforcement Technology (CET)
> extension through -mibt, -mshstk, -mcet options. One of these
> options has to accompany the -fcf-protection option to enable
> the code instrumentation for control-flow protection.
>   

Igor

[PATCH] CET shouldn't be enabled in 32-bit run-time libraries by defualt

[Tsimbalist, Igor V]

ENDBR32 and RDSSPD are multi-byte NOPs on x86-64 processors and
newer x86 processors, starting Pentium Pro.  They are UD on older 32-bit
processors. Detect this at configure time and adjust the default value
for enable_cet. GCC will enable CET in 32-bit run-time libraries in any case
if --enable-cet is used to configure GCC.

OK for trunk?

Igor




0001-CET-shouldn-t-be-enabled-in-32-bit-run-time-librarie.patch
Description: 0001-CET-shouldn-t-be-enabled-in-32-bit-run-time-librarie.patch

RE: PR84239, Reimplement CET intrinsics for rdssp/incssp insn

[Tsimbalist, Igor V]

> -Original Message-
> From: Sandra Loosemore [mailto:san...@codesourcery.com]
> Sent: Friday, February 9, 2018 7:42 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Cc: Uros Bizjak <ubiz...@gmail.com>
> Subject: Re: PR84239, Reimplement CET intrinsics for rdssp/incssp insn
> 
> On 02/09/2018 05:50 AM, Tsimbalist, Igor V wrote:
> > Introduce a couple of new CET intrinsics for reading and updating a
> shadow stack
> > pointer (_get_ssp and _inc_ssp), which are more user friendly. They replace
> the existing
> > _rdssp[d|q] and _incssp[d|q] instrinsics. The _get_ssp intrinsic has more
> deterministic
> > semantic: it returns a value of the shadow stack pointer if HW is CET
> capable and
> > 0 otherwise.
> >
> > Ok for trunk?
> 
> Just reviewing the documentation part:
> 
> > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> > index cb9df97..9f25dd9 100644
> > --- a/gcc/doc/extend.texi
> > +++ b/gcc/doc/extend.texi
> > @@ -12461,6 +12461,7 @@ instructions, but allow the compiler to
> schedule those calls.
> >  * TILEPro Built-in Functions::
> >  * x86 Built-in Functions::
> >  * x86 transactional memory intrinsics::
> > +* x86 control-flow protection intrinsics::
> >  @end menu
> >
> >  @node AArch64 Built-in Functions
> > @@ -21772,13 +21773,17 @@ void __builtin_ia32_wrpkru (unsigned int)
> >  unsigned int __builtin_ia32_rdpkru ()
> >  @end smallexample
> >
> > -The following built-in functions are available when @option{-mcet} is
> used.
> > -They are used to support Intel Control-flow Enforcment Technology (CET).
> > -Each built-in function generates the  machine instruction that is part of
> the
> > -function's name.
> > +The following built-in functions are available when @option{-mcet} or
> > +@option{-mshstk} option is used.  They support shadow stack
> > +machine instructions from Intel Control-flow Enforcment Technology
> (CET).
> 
> s/Enforcment/Enforcement/
> 
> > +Each built-in function generates the  machine instruction that is part
> > +of the function's name.  These are the internal low level functions.
> 
> s/low level/low-level/
> 
> > +Normally the functions in @ref{x86 control-flow protection intrinsics}
> > +should be used instead.
> > +
> >  @smallexample
> > -unsigned int __builtin_ia32_rdsspd (unsigned int)
> > -unsigned long long __builtin_ia32_rdsspq (unsigned long long)
> > +unsigned int __builtin_ia32_rdsspd (void)
> > +unsigned long long __builtin_ia32_rdsspq (void)
> >  void __builtin_ia32_incsspd (unsigned int)
> >  void __builtin_ia32_incsspq (unsigned long long)
> >  void __builtin_ia32_saveprevssp(void);
> > @@ -21885,6 +21890,51 @@ else
> >  Note that, in most cases, the transactional and non-transactional code
> >  must synchronize together to ensure consistency.
> >
> > +@node x86 control-flow protection intrinsics
> > +@subsection x86 Control-Flow Protection Intrinsics
> > +
> > +@deftypefn {CET Function} {ret_type} _get_ssp (void)
> > +The @code{ret_type} is @code{unsigned long long} for x86-64 platform
> > +and @code{unsigned int} for x86 pltform.
> 
> I'd prefer the sentence about the return type be placed after the
> description of what the function does.  And please fix typos:
> s/x86-64 platform/64-bit targets/
> s/x86 pltform/32-bit targets/
> 
> > +Get the current value of shadow stack pointer if shadow stack support
> > +from Intel CET is enabled in the HW or @code{0} otherwise.
> 
> s/HW/hardware,/
> 
> > +@end deftypefn
> > +
> > +@deftypefn {CET Function} void _inc_ssp (unsigned int)
> > +Increment the current shadow stack pointer by the size specified by the
> > +function argument.  For security reason only unsigned byte value is used
> > +from the argument.  Therefore for the size greater than @code{255} the
> > +function should be called several times.
> 
> How about rephrasing the last two sentences:
> 
> The argument is masked to a byte value for security reasons, so to
> increment by more than 255 bytes you must call the function multiple times.
> 
> > +@end deftypefn
> > +
> > +The shadow stack unwind code looks like:
> > +
> > +@smallexample
> > +#include 
> > +
> > +/* Unwind the shadow stack for EH.  */
> > +#define _Unwind_Frames_Extra(x)\
> > +  do   \
> > +@{ \
> > +  _Unwind_Word ssp = _get_ssp ();  \
> > +  i

PR84239, Reimplement CET intrinsics for rdssp/incssp insn

[Tsimbalist, Igor V]

Introduce a couple of new CET intrinsics for reading and updating a shadow stack
pointer (_get_ssp and _inc_ssp), which are more user friendly. They replace the 
existing
_rdssp[d|q] and _incssp[d|q] instrinsics. The _get_ssp intrinsic has more 
deterministic
semantic: it returns a value of the shadow stack pointer if HW is CET capable 
and
0 otherwise.

Ok for trunk?

Igor




0001-Reimplement-CET-intrinsics-for-rdssp-incssp-insn.patch
Description: 0001-Reimplement-CET-intrinsics-for-rdssp-incssp-insn.patch

RE: PR 84154: Fix checking -mibt and -mshstk options for control flow protection

[Tsimbalist, Igor V]

> -Original Message-
> From: Paolo Carlini [mailto:paolo.carl...@oracle.com]
> Sent: Wednesday, February 7, 2018 12:46 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Cc: Nick Clifton <ni...@redhat.com>; hjl.to...@gmail.com; Uros Bizjak
> <ubiz...@gmail.com>
> Subject: Re: PR 84154: Fix checking -mibt and -mshstk options for control
> flow protection
> 
> Hi,
> 
> on a rather old x86_64-linux machine GCC doesn't build anymore with
> r257414:
> 
> libtool: compile:  /xxx/Gcc/svn-dirs/trunk-build/./gcc/xg++
> -B/xxx/Gcc/svn-dirs/trunk-build/./gcc/ -nostdinc++ -nostdinc++
> -I/xxx/Gcc/svn-dirs/trunk-build/x86_64-pc-linux-gnu/libstdc++-
> v3/include/x86_64-pc-linux-gnu
> -I/xxx/Gcc/svn-dirs/trunk-build/x86_64-pc-linux-gnu/libstdc++-v3/include
> -I/xxx/Gcc/svn-dirs/trunk/libstdc++-v3/libsupc++
> -I/xxx/Gcc/svn-dirs/trunk/libstdc++-v3/include/backward
> -I/xxx/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/util
> -L/xxx/Gcc/svn-dirs/trunk-build/x86_64-pc-linux-gnu/libstdc++-v3/src
> -L/xxx/Gcc/svn-dirs/trunk-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
> -L/xxx/Gcc/svn-dirs/trunk-build/x86_64-pc-linux-gnu/libstdc++-
> v3/libsupc++/.libs
> -B/xxx/Gcc/svn-dirs/trunk-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
> -B/xxx/Gcc/svn-dirs/trunk-build/x86_64-pc-linux-gnu/libstdc++-
> v3/libsupc++/.libs
> -B/xxx/Gcc/svn-dirs/trunk-install/x86_64-pc-linux-gnu/bin/
> -B/xxx/Gcc/svn-dirs/trunk-install/x86_64-pc-linux-gnu/lib/ -isystem
> /xxx/Gcc/svn-dirs/trunk-install/x86_64-pc-linux-gnu/include -isystem
> /xxx/Gcc/svn-dirs/trunk-install/x86_64-pc-linux-gnu/sys-include
> -DHAVE_CONFIG_H -I. -I../../../trunk/libitm
> -I../../../trunk/libitm/config/linux/x86
> -I../../../trunk/libitm/config/linux -I../../../trunk/libitm/config/x86
> -I../../../trunk/libitm/config/posix
> -I../../../trunk/libitm/config/generic -I../../../trunk/libitm -mrtm
> -Wall -pthread -Werror -fcf-protection -mcet -std=gnu++0x
> -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -O2
> -D_GNU_SOURCE -MT beginend.lo -MD -MP -MF .deps/beginend.Tpo -c
> ../../../trunk/libitm/beginend.cc  -fPIC -DPIC -o .libs/beginend.o
> In file included from
> /xxx/Gcc/svn-dirs/trunk-build/gcc/include/x86intrin.h:27,
>   from ../../../trunk/libitm/config/x86/target.h:26,
>   from ../../../trunk/libitm/libitm_i.h:74,
>   from ../../../trunk/libitm/barrier.cc:25:
> /xxx/Gcc/svn-dirs/trunk-build/gcc/include/ia32intrin.h:56:28: internal
> compiler error: in ix86_option_override_internal, at config/i386/i386.c:4952
>   #pragma GCC target("sse4.2")

The issue is known and is covered by 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84248. The patch has been posted

https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00276.html

Igor

> Paolo.

RE: PR 84154: Fix checking -mibt and -mshstk options for control flow protection

[Tsimbalist, Igor V]

> -Original Message-
> From: Rainer Orth [mailto:r...@cebitec.uni-bielefeld.de]
> Sent: Tuesday, February 6, 2018 11:50 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: gcc-patches@gcc.gnu.org; Nick Clifton <ni...@redhat.com>;
> hjl.to...@gmail.com; Uros Bizjak <ubiz...@gmail.com>
> Subject: Re: PR 84154: Fix checking -mibt and -mshstk options for control
> flow protection
> 
> Hi Igor,
> 
> > Here is the updated patch. Please note the subject should say PR 84145.
> 
> the two new testcases FAIL on all non-x86 targets (I've seen that on
> sparc-sun-solaris2.11, there's a gcc-testresults posting for
> powerpc64le-unknown-linux-gnu, and PR testsuite/84243 reports it for
> aarch64-none-linux-gnu:
> 
> +FAIL: c-c++-common/fcf-protection-6.c  -std=gnu++11  (test for errors,
> line )
> +FAIL: c-c++-common/fcf-protection-6.c  -std=gnu++11 (test for excess
> errors)
> +FAIL: c-c++-common/fcf-protection-6.c  -std=gnu++14  (test for errors,
> line )
> +FAIL: c-c++-common/fcf-protection-6.c  -std=gnu++14 (test for excess
> errors)
> +FAIL: c-c++-common/fcf-protection-6.c  -std=gnu++98  (test for errors,
> line )
> +FAIL: c-c++-common/fcf-protection-6.c  -std=gnu++98 (test for excess
> errors)
> 
> Excess errors:
> xg++: error: unrecognized command line option '-mshstk'
> 
> +FAIL: c-c++-common/fcf-protection-7.c  -std=gnu++11  (test for errors,
> line )
> +FAIL: c-c++-common/fcf-protection-7.c  -std=gnu++11 (test for excess
> errors)
> +FAIL: c-c++-common/fcf-protection-7.c  -std=gnu++14  (test for errors,
> line )
> +FAIL: c-c++-common/fcf-protection-7.c  -std=gnu++14 (test for excess
> errors)
> +FAIL: c-c++-common/fcf-protection-7.c  -std=gnu++98  (test for errors,
> line )
> +FAIL: c-c++-common/fcf-protection-7.c  -std=gnu++98 (test for excess
> errors)
> 
> Excess errors:
> xg++: error: unrecognized command line option '-mibt'
> 
> I think the right way to handle that is to pass -mshstk resp. -mibt on
> x86 only.  The following patch does this; tested with the appropriate
> runtest invocation on i386-pc-solaris2.11 and sparc-sun-solaris2.11.
> 
> Ok for mainline?

Agree with the fix. Thanks for taking care of this issue.

Igor

>   Rainer
> 
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
> 
> 
> 2018-02-06  Rainer Orth  <r...@cebitec.uni-bielefeld.de>
> 
>   PR testsuite/84243
>   * c-c++-common/fcf-protection-6.c: Only pass -mshstk on x86
>   targets.
>   * c-c++-common/fcf-protection-7.c: Likewise for -mibt.

RE: [PATCH] i386: Mask out the CF_SET bit for -fcf-protection check

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Tuesday, February 6, 2018 10:09 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Uros Bizjak <ubiz...@gmail.com>; Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com>
> Subject: [PATCH] i386: Mask out the CF_SET bit for -fcf-protection check
> 
> Since ix86_option_override_internal sets the CF_SET bit in
> flag_cf_protection and it can be called more than once via pragma,
> we need to mask out the CF_SET bit when checking flag_cf_protection.
> 
> OK for trunk if there is no regression?

Ok from CET viewpoint.

Thanks,
Igor

> H.J.
> ---
>   PR target/84248
>   * config/i386/i386.c (ix86_option_override_internal): Mask out
>   the CF_SET bit when checking -fcf-protection.
> ---
>  gcc/config/i386/i386.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 6c612c77987..ef7ff89bcbb 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -4913,12 +4913,12 @@ ix86_option_override_internal (bool
> main_args_p,
>= build_target_option_node (opts);
> 
>/* Do not support control flow instrumentation if CET is not enabled.  */
> -  if (opts->x_flag_cf_protection != CF_NONE)
> +  cf_protection_level cf_protection
> += (cf_protection_level) (opts->x_flag_cf_protection & ~CF_SET);
> +  if (cf_protection != CF_NONE)
>  {
> -  switch (flag_cf_protection)
> +  switch (cf_protection)
>   {
> - case CF_NONE:
> -   break;
>   case CF_BRANCH:
> if (! TARGET_IBT_P (opts->x_ix86_isa_flags2))
>   {
> @@ -4953,7 +4953,7 @@ ix86_option_override_internal (bool main_args_p,
>   }
> 
>opts->x_flag_cf_protection =
> - (cf_protection_level) (opts->x_flag_cf_protection | CF_SET);
> + (cf_protection_level) (cf_protection | CF_SET);
>  }
> 
>if (ix86_tune_features [X86_TUNE_AVOID_128FMA_CHAINS])
> --
> 2.14.3

RE: [PATCH] Use -fcf-protection=return in cet-intrin-4.c

[Tsimbalist, Igor V]

> -Original Message-
> From: Lu, Hongjiu
> Sent: Tuesday, February 6, 2018 10:03 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Uros Bizjak <ubiz...@gmail.com>; Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com>
> Subject: [PATCH] Use -fcf-protection=return in cet-intrin-4.c
> 
> Since -fcf-protection requires both -mshstk and -mibt, use
> -fcf-protection=return with -mshstk in cet-intrin-4.c.
> 
> OK for trunk?

Ok from CET viewpoint.

Igor

> H.J.
> --
>   PR target/84243
>   * gcc.target/i386/cet-intrin-4.c (dg-options): Use
>   -fcf-protection=return.
> ---
>  gcc/testsuite/gcc.target/i386/cet-intrin-4.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/gcc.target/i386/cet-intrin-4.c
> b/gcc/testsuite/gcc.target/i386/cet-intrin-4.c
> index 76ec160543f..437a4cd690c 100644
> --- a/gcc/testsuite/gcc.target/i386/cet-intrin-4.c
> +++ b/gcc/testsuite/gcc.target/i386/cet-intrin-4.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O -fcf-protection -mshstk" } */
> +/* { dg-options "-O -fcf-protection=return -mshstk" } */
>  /* { dg-final { scan-assembler "rdsspd|incsspd\[ \t]+(%|)eax" { target ia32 
> } } }
> */
>  /* { dg-final { scan-assembler "rdssp\[dq]\[ \t]+(%|)\[re]ax"  { target { ! 
> ia32 } }
> } } */
>  /* { dg-final { scan-assembler "incssp\[dq]\[ \t]+(%|)\[re]di" { target { ! 
> ia32 } }
> } } */
> --
> 2.14.3

RE: [PATCH] Fix ICE with CET and -g (PR target/84146)

[Tsimbalist, Igor V]

> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, January 31, 2018 9:57 PM
> To: Uros Bizjak <ubiz...@gmail.com>; Kirill Yukhin
> <kirill.yuk...@gmail.com>
> Cc: gcc-patches@gcc.gnu.org; Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com>
> Subject: [PATCH] Fix ICE with CET and -g (PR target/84146)
> 
> Hi!
> 
> We ICE on the following test because rest_of_insert_endbranch
> separates a setjmp call from the following
> NOTE_INSN_CALL_ARG_LOCATION
> that must always immediately follow the call.
> No other note or debug insn (which aren't around after var-tracking anyway)
> needs to follow the call, so the loop it was doing is unnecessary, on the
> other side, we are already at a late state where bb boundaries are fuzzy and
> we are going to throw away the cfg before doing final.
> 
> So, all we need is just check if the call is followed by this note and
> if yes, emit the endbr after it.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Just in case, ok from CET viewpoint.

Thanks,
Igor

> 2018-01-31  Jakub Jelinek  <ja...@redhat.com>
> 
>   PR target/84146
>   * config/i386/i386.c (rest_of_insert_endbranch): Only skip
>   NOTE_INSN_CALL_ARG_LOCATION after a call, not anything else,
>   and skip it regardless of bb boundaries.  Use CALL_P macro,
>   don't test INSN_P (insn) together with CALL_P or JUMP_P check
>   unnecessarily, formatting fix.
> 
>   * gcc.target/i386/pr84146.c: New test.
> 
> --- gcc/config/i386/i386.c.jj 2018-01-31 09:26:18.341505667 +0100
> +++ gcc/config/i386/i386.c2018-01-31 14:13:33.815243832 +0100
> @@ -2609,31 +2609,27 @@ rest_of_insert_endbranch (void)
>for (insn = BB_HEAD (bb); insn != NEXT_INSN (BB_END (bb));
>  insn = NEXT_INSN (insn))
>   {
> -   if (INSN_P (insn) && GET_CODE (insn) == CALL_INSN)
> +   if (CALL_P (insn))
>   {
> if (find_reg_note (insn, REG_SETJMP, NULL) == NULL)
>   continue;
> /* Generate ENDBRANCH after CALL, which can return more
> than
>twice, setjmp-like functions.  */
> 
> -   /* Skip notes and debug insns that must be next to the
> -  call insn.  ??? This might skip a lot more than
> -  that...  ??? Skipping barriers and emitting code
> -  after them surely looks like a mistake; we probably
> -  won't ever hit it, for we'll hit BB_END first.  */
> +   /* Skip notes that must immediately follow the call insn.  */
> rtx_insn *next_insn = insn;
> -   while ((next_insn != BB_END (bb))
> -   && (DEBUG_INSN_P (NEXT_INSN (next_insn))
> -   || NOTE_P (NEXT_INSN (next_insn))
> -   || BARRIER_P (NEXT_INSN (next_insn
> - next_insn = NEXT_INSN (next_insn);
> +   if (NEXT_INSN (insn)
> +   && NOTE_P (NEXT_INSN (insn))
> +   && (NOTE_KIND (NEXT_INSN (insn))
> +   == NOTE_INSN_CALL_ARG_LOCATION))
> + next_insn = NEXT_INSN (insn);
> 
> cet_eb = gen_nop_endbr ();
> emit_insn_after_setloc (cet_eb, next_insn, INSN_LOCATION
> (insn));
> continue;
>   }
> 
> -   if (INSN_P (insn) && JUMP_P (insn) && flag_cet_switch)
> +   if (JUMP_P (insn) && flag_cet_switch)
>   {
> rtx target = JUMP_LABEL (insn);
> if (target == NULL_RTX || ANY_RETURN_P (target))
> @@ -2668,7 +2664,7 @@ rest_of_insert_endbranch (void)
> if ((LABEL_P (insn) && LABEL_PRESERVE_P (insn))
> || (NOTE_P (insn)
> && NOTE_KIND (insn) == NOTE_INSN_DELETED_LABEL))
> -/* TODO.  Check /s bit also.  */
> + /* TODO.  Check /s bit also.  */
>   {
> cet_eb = gen_nop_endbr ();
> emit_insn_after (cet_eb, insn);
> --- gcc/testsuite/gcc.target/i386/pr84146.c.jj2018-01-31
> 16:32:28.099929916 +0100
> +++ gcc/testsuite/gcc.target/i386/pr84146.c   2018-01-31
> 14:04:17.796122397 +0100
> @@ -0,0 +1,14 @@
> +/* PR target/84146 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -g -mcet -fcf-protection=full" } */
> +
> +int __setjmp (void **);
> +void *buf[64];
> +
> +void
> +foo (void)
> +{
> +  __setjmp (buf);
> +  for (;;)
> +;
> +}
> 
>   Jakub

RE: PR 84154: Fix checking -mibt and -mshstk options for control flow protection

[Tsimbalist, Igor V]

> -Original Message-
> From: Nick Clifton [mailto:ni...@redhat.com]
> Sent: Tuesday, February 6, 2018 1:16 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; hjl.to...@gmail.com
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: PR 84154: Fix checking -mibt and -mshstk options for control
> flow protection
> 
> Hi Igor,
> 
> >>   Attached is a potential patch for PR 84145:
> >>
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84145
> 
> > Coincidentally, I have worked on the same patch.
> 
> Great minds, etc :-)
> 
> > Please look at the patch, I uploaded it to the bug. The main differences are
> >
> > - updated the output messages to be more informative;
> > - updated  the tests and add couple of new tests to check the messages;
> > - fixed a typo in the doc file related to fcf-protection;
> >
> > I am ok with the changes in i386.c but would like to update the messages.
> Could you incorporate my changes and proceed? Or would you like me to
> finish the fix?
> 
> If you are happy to finish the fix then please do so.  Your fix is
> more thorough than mine, so I am happy to see it go on.  Although
> I should say that I am not an x86 maintainer, so I cannot approve
> it.

Here is the updated patch. Please note the subject should say PR 84145.

Ok for trunk?

> Cheers
>   Nick
> 



0001-Fix-checking-mibt-and-mshstk-options-for-control-flo.patch
Description: 0001-Fix-checking-mibt-and-mshstk-options-for-control-flo.patch

RE: PR 84154: Fix checking -mibt and -mshstk options for control flow protection

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Nick Clifton
> Sent: Monday, February 5, 2018 4:15 PM
> To: hjl.to...@gmail.com
> Cc: gcc-patches@gcc.gnu.org
> Subject: RFA: PR 84154: Fix checking -mibt and -mshstk options for control
> flow protection
> 
> Hi H.J.
> 
>   Attached is a potential patch for PR 84145:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84145
> 
>   The problem was that the code to check that the --mibt and/or -mshstk
>   options have been correctly enabled for control flow protection did
>   not take into account that the wrong option might have been enabled.
> 
>   So the patch inverts the test, looking at the value of
>   flag_cf_protection first and then checking to see if the needed x86
>   specific options have been enabled.  This gives results like this:
> 
> 
>% gcc -c main.c
>% gcc -c main.c -fcf-protection=full
> cc1: error: '-fcf-protection=full' requires CET support on this target. Use -
> mcet or both of -mibt and -mshstk options to enable CET
>% gcc -c main.c -fcf-protection=full -mcet
>% gcc -c main.c -fcf-protection=full -mibt
> cc1: error: '-fcf-protection=full' requires CET support on this target. Use -
> mcet or both of -mibt and -mshstk options to enable CET
>% gcc -c main.c -fcf-protection=full -mibt -mshstk
>% gcc -c main.c -fcf-protection=branch
> cc1: error: '-fcf-protection=branch' requires CET support on this target. Use 
> -
> mcet or -mibt to enable CET
>% gcc -c main.c -fcf-protection=branch -mcet
>% gcc -c main.c -fcf-protection=branch -mibt
>% gcc -c main.c -fcf-protection=branch -mshstk
> cc1: error: '-fcf-protection=branch' requires CET support on this target. Use 
> -
> mcet or -mibt to enable CET
>% gcc -c main.c -fcf-protection=return
> cc1: error: '-fcf-protection=return' requires CET support on this target. Use 
> -
> mcet or -mshstk to enable CET
>% gcc -c main.c -fcf-protection=return -mcet
>% gcc -c main.c -fcf-protection=return -mibt
> cc1: error: '-fcf-protection=return' requires CET support on this target. Use 
> -
> mcet or -mshstk to enable CET
>% gcc -c main.c -fcf-protection=return -mshstk
>%
> 
>   What do you think ?  Is the patch OK for the mainline ?

Coincidentally, I have worked on the same patch. Please look at the patch, I 
uploaded it to the bug. The main differences are

- updated the output messages to be more informative;
- updated  the tests and add couple of new tests to check the messages;
- fixed a typo in the doc file related to fcf-protection;

I am ok with the changes in i386.c but would like to update the messages. Could 
you incorporate my changes and proceed? Or would you like me to finish the fix?

Thanks,
Igor

> Cheers
>   Nick
> 
> gcc/ChangeLog
> 2018-02-05  Nick Clifton  
> 
>   PR 84145
>   * config/i386/i386.c (ix86_option_override_internal): Rework
>   checks for -fcf-protection and -mibt/-mshstk.
> 
> Index: gcc/config/i386/i386.c
> ===
> 
> --- gcc/config/i386/i386.c(revision 257389)
> +++ gcc/config/i386/i386.c(working copy)
> @@ -4915,30 +4915,43 @@
>/* Do not support control flow instrumentation if CET is not enabled.  */
>if (opts->x_flag_cf_protection != CF_NONE)
>  {
> -  if (!(TARGET_IBT_P (opts->x_ix86_isa_flags2)
> - || TARGET_SHSTK_P (opts->x_ix86_isa_flags)))
> +  switch (flag_cf_protection)
>   {
> -   if (flag_cf_protection == CF_FULL)
> + case CF_NONE:
> +   break;
> + case CF_BRANCH:
> +   if (! TARGET_IBT_P (opts->x_ix86_isa_flags2))
>   {
> -   error ("%<-fcf-protection=full%> requires CET support "
> -  "on this target. Use -mcet or one of -mibt, "
> -  "-mshstk options to enable CET");
> +   error ("%<-fcf-protection=branch%> requires CET support "
> +  "on this target. Use -mcet or -mibt to enable CET");
> +   flag_cf_protection = CF_NONE;
> +   return false;
>   }
> -   else if (flag_cf_protection == CF_BRANCH)
> +   break;
> + case CF_RETURN:
> +   if (! TARGET_SHSTK_P (opts->x_ix86_isa_flags))
>   {
> -   error ("%<-fcf-protection=branch%> requires CET support "
> -  "on this target. Use -mcet or one of -mibt, "
> -  "-mshstk options to enable CET");
> +   error ("%<-fcf-protection=return%> requires CET support "
> +  "on this target. Use -mcet or -mshstk to enable CET");
> +   flag_cf_protection = CF_NONE;
> +   return false;
>   }
> -   else if (flag_cf_protection == CF_RETURN)
> +   break;
> + case CF_FULL:
> +   if (   ! TARGET_IBT_P (opts->x_ix86_isa_flags2)
> +  || ! TARGET_SHSTK_P (opts->x_ix86_isa_flags))
>   {
> -   error 

RE: [PATCH][PR target/84066] Wrong shadow stack register size is saved for x32

[Tsimbalist, Igor V]

> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Tuesday, January 30, 2018 3:45 PM
> To: Uros Bizjak <ubiz...@gmail.com>
> Cc: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH][PR target/84066] Wrong shadow stack register size is
> saved for x32
> 
> On Tue, Jan 30, 2018 at 6:38 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
> > On Tue, Jan 30, 2018 at 3:19 PM, Tsimbalist, Igor V
> > <igor.v.tsimbal...@intel.com> wrote:
> >> x32 is a 64-bit process with 32-bit software pointer and kernel may
> >> place x32 shadow stack above 4GB.  We need to save and restore 64-bit
> >> shadow stack register for x32. builtin jmp buf size is 5 pointers.  We
> >> have space to save 64-bit shadow stack pointer: 32-bit SP, 32-bit FP,
> >> 32-bit IP, 64-bit SSP for x32.
> >>
> >> PR target/84066
> >> * gcc/config/i386/i386.md: Replace Pmode with word_mode in
> >> builtin_setjmp_setup and builtin_longjmp to support x32.
> >> * gcc/testsuite/gcc.target/i386/cet-sjlj-6.c: New test.
> >>
> >> Ok for trunk?
> >
> > LGTM, but please check the testcase with -mx32
> > -maddress-mode={short,long} nevertheless to catch any incosistencies.
> >
> 
> Speaking of -maddress-mode=, shouldn't
> 
> +  reg_adj = gen_rtx_SUBREG (Pmode, reg_ssp, 0);
>tmp = gen_rtx_SET (reg_adj,
>   gen_rtx_LSHIFTRT (Pmode, negate_rtx (Pmode, reg_adj),
> -   GEN_INT ((Pmode == SImode)
> +   GEN_INT ((word_mode == SImode)
>  ? 2
>  : 3)));
> 
> be
> 
> +  reg_adj = gen_rtx_SUBREG (ptr_mode, reg_ssp, 0);
>tmp = gen_rtx_SET (reg_adj,
>   gen_rtx_LSHIFTRT (ptr_mode, negate_rtx (ptr_mode, reg_adj),
> -   GEN_INT ((Pmode == SImode)
> +   GEN_INT ((word_mode == SImode)
>  ? 2
>  : 3)));
> 
> Pmode == word_mode for -maddress-mode=long.
> 
> +++ b/gcc/testsuite/gcc.target/i386/cet-sjlj-6.c
> @@ -0,0 +1,19 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O -fcf-protection -mcet -mx32" } */
> +/* { dg-final { scan-assembler-times "endbr64" 2 } } */
> +/* { dg-final { scan-assembler-times "movq\t.*buf\\+12" 1 } } */
> +/* { dg-final { scan-assembler-times "subq\tbuf\\+12" 1 } } */
> +/* { dg-final { scan-assembler-times "rdsspq" 2 } } */
> +/* { dg-final { scan-assembler-times "incsspq" 2 } } */
> 
> Please add a test for
> 
>tmp = gen_rtx_SET (reg_adj,
>   gen_rtx_LSHIFTRT (Pmode, negate_rtx (Pmode, reg_adj),
> -   GEN_INT ((Pmode == SImode)
> +   GEN_INT ((word_mode == SImode)
>  ? 2
>  : 3)));
> 
Thanks for suggestion about -maddress-mode option. The patch was updated
and new test was added. The -maddress-mode=long test is expected to
fail as it depends on fixing of 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84150

Ok for trunk?

Igor


0001-PR84066-Wrong-shadow-stack-register-size-is-saved-fo.patch
Description: 0001-PR84066-Wrong-shadow-stack-register-size-is-saved-fo.patch

[PATCH][PR target/84066] Wrong shadow stack register size is saved for x32

[Tsimbalist, Igor V]

x32 is a 64-bit process with 32-bit software pointer and kernel may
place x32 shadow stack above 4GB.  We need to save and restore 64-bit
shadow stack register for x32. builtin jmp buf size is 5 pointers.  We
have space to save 64-bit shadow stack pointer: 32-bit SP, 32-bit FP,
32-bit IP, 64-bit SSP for x32.

PR target/84066
* gcc/config/i386/i386.md: Replace Pmode with word_mode in
builtin_setjmp_setup and builtin_longjmp to support x32.
* gcc/testsuite/gcc.target/i386/cet-sjlj-6.c: New test.

Ok for trunk?

Igor




0001-PR84066-Wrong-shadow-stack-register-size-is-saved-fo.patch
Description: 0001-PR84066-Wrong-shadow-stack-register-size-is-saved-fo.patch

[PATCH/x86] Move mavx512vnni option from ix86_isa_flags2 to ix86_isa_flags.

[Tsimbalist, Igor V]

This is a follow up patch for pr83488 to fix an error in setting
OPTION_MASK_ISA_AVX512VNNI_SET and OPTION_MASK_ISA_AVX512F_SET bits.
There were both set in ix86_isa_flags2 while being defined in
different ISA sets. Additionally move OPTION_MASK_ISA_AVX512VNNI_SET
to ix86_isa_flags as it can be used with OPTION_MASK_ISA_AVX512VL_SET.

gcc/
    * common/config/i386/i386-common.c 
(OPTION_MASK_ISA_AVX512VNNI_SET):
    Or in OPTION_MASK_ISA_AVX512F_SET.
    (OPTION_MASK_ISA_AVX512F_UNSET): Or in
    OPTION_MASK_ISA_AVX512VNNI_UNSET.
    (ix86_handle_option): Adjust for
    OPTION_MASK_ISA_AVX512VNNI_*SET being in ix86_isa_flags.
    * config/i386/i386-builtin.def: Move VNNI builtins from ARGS2
    section to ARGS.
    * config/i386/i386-c.c: Check for OPTION_MASK_ISA_AVX512VNNI in
    isa_flag instead of isa_flag2.
    * config/i386/i386.c (ix86_target_string): Move -mavx512vnni 
from
    isa_opts2 to isa_opts.
    * config/i386/i386.opt (mavx512vnni): Move from ix86_isa_flags2
    to ix86_isa_flags.

Ok for trunk?

Igor



0001-Move-mavx512vnni-option-from-ix86_isa_flags2-to-ix86.patch
Description: 0001-Move-mavx512vnni-option-from-ix86_isa_flags2-to-ix86.patch

RE: [i386] PR81842 [CET] -fcf-protection -mcet is incompatible with makecontext family functions

[Tsimbalist, Igor V]

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, December 19, 2017 6:15 AM
> To: Sandra Loosemore <san...@codesourcery.com>; Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com>; gcc-patches@gcc.gnu.org
> Cc: Uros Bizjak <ubiz...@gmail.com>
> Subject: Re: [i386] PR81842 [CET] -fcf-protection -mcet is incompatible with
> makecontext family functions
> 
> On 12/18/2017 12:39 PM, Sandra Loosemore wrote:
> > On 12/17/2017 05:05 PM, Tsimbalist, Igor V wrote:
> >> -fcf-protection -mcet is incompatible with makecontext family functions
> >> since they can't properly set up and destroy shadow stack pointer. This
> >> change provides a mechanism to help detection shadow stack
> compatibility.
> >> The current proposal is to add -mcheck-shstk-compat option which will
> >> predefine __CHECK_SHSTK_COMPAT__ macro. The option will be
> >> set on by default.  Then we can add a code
> >>
> >> #if defined __SHSTK__ && defined __CHECK_SHSTK_COMPAT__
> >> # error This source is incompatible with -mshstk
> >> #endif
> >>
> >> to .
> >
> > The functional change here is out of my maintainership domain, but
> > Why does this need a new macro and a new option to control it?  If the
> > code being protected doesn't work properly with -mshstk, it seems like
> > it would be more robust to do just
> >
> > #if defined __SHSTK__
> > # error This source is incompatible with -mshstk
> > #endif
> >
> > I don't see any discussion in the bugzilla issue to explain this.
> I'd tend to agree.  Making another option to handle this seems excessive.
I replied to Sandra's email and updated the bugzilla issue.

Igor

> jeff

RE: [i386] PR81842 [CET] -fcf-protection -mcet is incompatible with makecontext family functions

[Tsimbalist, Igor V]

> -Original Message-
> From: Sandra Loosemore [mailto:san...@codesourcery.com]
> Sent: Monday, December 18, 2017 8:39 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Cc: Uros Bizjak <ubiz...@gmail.com>
> Subject: Re: [i386] PR81842 [CET] -fcf-protection -mcet is incompatible with
> makecontext family functions
> 
> On 12/17/2017 05:05 PM, Tsimbalist, Igor V wrote:
> > -fcf-protection -mcet is incompatible with makecontext family functions
> > since they can't properly set up and destroy shadow stack pointer. This
> > change provides a mechanism to help detection shadow stack
> compatibility.
> > The current proposal is to add -mcheck-shstk-compat option which will
> > predefine __CHECK_SHSTK_COMPAT__ macro. The option will be
> > set on by default.  Then we can add a code
> >
> > #if defined __SHSTK__ && defined __CHECK_SHSTK_COMPAT__
> > # error This source is incompatible with -mshstk
> > #endif
> >
> > to .
> 
> The functional change here is out of my maintainership domain, but
> Why does this need a new macro and a new option to control it?  If the
> code being protected doesn't work properly with -mshstk, it seems like
> it would be more robust to do just
> 
> #if defined __SHSTK__
> # error This source is incompatible with -mshstk
> #endif
> 
> I don't see any discussion in the bugzilla issue to explain this.

This option is needed to support  two cases:

1. Compilation of ucontext functions inside glibc. To have glibc itself be CET
compatible all files comprises the library has to be CET compatible. That means
the module with ucontext functions from glibc has to be forced to be CET
compatible.

2. Compilation of a user application with ucontext functions. In this case the
error has to be issued, so no usage of a ucontext functions.

Having just __SHSTK__ macro it's impossible to handle both cases. The case
#1 will report an error during glibc compilation. A new macro is introduced to
use in the source to handle these cases. To control the value of the new macro
a new option is introduced.

A separate discussion was started by HJ to what is the best way to handle
ucontext functions in presence of CET. The proposal is to introduce a new 
interface,
that can properly handle shadow stack (but this it out of this PR).

I have added this info to the bugzilla issue.

> Re the proposed documentation for the new option:
> 
> > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > index 1413095..7b4223a 100644
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -26225,6 +26225,15 @@ The option has effect only if the @option{-fcf-
> protection=full} or
> >  @option{-mshstk} is on by default when the @option{-mcet} option is
> >  specified.
> >
> > +@item -mcheck-shstk-compat
> > +@opindex mcheck-shstk-compat
> > +This option predefines __CHECK_SHSTK_COMPAT__ macro, which can be
> used
> 
> You need to add @code markup on all the macro names here.
Done.

> > +to add a guard to the C/C++ sources which are incompatible with Intel
> 
> s/which/that/
Fixed.

Igor

> > +shadow stack technology.  A typical case would be issuing an error when >
> +both __SHSTK__ and __CHECK_SHSTK_COMPAT__ macro are defined.  The
> option
> > +@option{-mcheck-shstk-compat} is on by default when the @code{-
> mshstk}
> > +option is specified.
> > +
> >  @item -mcrc32
> >  @opindex mcrc32
> >  This option enables built-in functions @code{__builtin_ia32_crc32qi},
> 
> -Sandra

[i386] PR81842 [CET] -fcf-protection -mcet is incompatible with makecontext family functions

[Tsimbalist, Igor V]

-fcf-protection -mcet is incompatible with makecontext family functions
since they can't properly set up and destroy shadow stack pointer. This
change provides a mechanism to help detection shadow stack compatibility.
The current proposal is to add -mcheck-shstk-compat option which will
predefine __CHECK_SHSTK_COMPAT__ macro. The option will be
set on by default.  Then we can add a code

#if defined __SHSTK__ && defined __CHECK_SHSTK_COMPAT__
# error This source is incompatible with -mshstk
#endif

to .

Ok for trunk?

Igor


0001-Add-mcheck-shstk-compat.patch
Description: 0001-Add-mcheck-shstk-compat.patch

RE: [compare-debug] use call loc for nop_endbr

[Tsimbalist, Igor V]

> -Original Message-
> From: Alexandre Oliva [mailto:aol...@redhat.com]
> Sent: Thursday, December 14, 2017 7:37 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [compare-debug] use call loc for nop_endbr
> 
> On Dec 14, 2017, "Tsimbalist, Igor V" <igor.v.tsimbal...@intel.com> wrote:
> 
> >> Regstrapping with -fcompare-debug on stage3 host and target builds on
> >> x86_64- and i686-linux-gnu; ok to install?
> 
> > Ok from me.
> 
> Thanks, I went ahead and installed it.
> 
> > Am I correct the error you had was related to improper location
> information,
> 
> Yeah, only location information.
> 
> > I will try to skip NOTE insns only.
> 
> You probably want to skip debug insns and notes, too.  Actually, IIRC
> you insert these insns after var-tracking, so you probably only have to
> deal with notes.  You don't have to, but if bindings are intended to
> take effect right after the call, it would probably be nice if they
> still did so, e.g., even if you happen to single-step out of the call
> and stop at the nop_endbr insn.
Yes, I expect this behavior.

> BTW, is this the subject of a Cauldron 2017 talk in which I raised an
> issue about PLT entries possibly needing special opcodes to enable them
> to be used as call targets or somesuch?  I had initially retracted my
> question, when it was stated that only indirect calls needed special
> treatment, but later I realized that in some cases PLT entries *are*
> used as function addresses even for functions that have their addresses
> taken.  Please let me know if you're familiar with the issue and would
> like me to detail the problem.
Please give more info. I do not remember all details but PLT entries
were changes to have endbr instruction (if this is relevant to your question :).
HJ did this.

Thanks,
Igor

> --
> Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member
> Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

RE: [compare-debug] use call loc for nop_endbr

[Tsimbalist, Igor V]

> -Original Message-
> From: Alexandre Oliva [mailto:aol...@redhat.com]
> Sent: Wednesday, December 13, 2017 8:34 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Subject: [compare-debug] use call loc for nop_endbr
> 
> We skip debug insns and notes after a call that needs a nop_endbr, but
> since a debug insn could be the last in a block, it may affect the loc
> in the emitted nop_endbr insn.  Although this has no effect on
> codegen, it does mess with debug info a bit, and it causes
> -fcompare-debug to fail for e.g. libsanitizer's
> tsan/tsan_platform_linux.cc on x86_64.
> 
> So, pick the location of the call insn for the nop_endbr insn, to
> avoid the line number differences in dumps, including -fcompare-debug
> ones.
> 
> Also, we don't need to determine what the insert point would be unless
> we're actually emitting the nop_endbr insn after the call, so
> rearrange the code to avoid wasting cycles.
> 
> Finally, it seems like testing for barriers is a mistake.  We probably
> never actually pass that test, for the barriers would hit BB_END
> first.  If we did, we'd end up emitting the nop_endbr outside any BB,
> even after the end of the function!  That would be Very Bad (TM).
> Now, since the test as it is can't hurt, I figured I wouldn't change
> the logic right now, just add a comment so that someone involved in
> endbr stuff can have a second look and hopefully fix it.
> 
> I'd appreciate if you'd try to drop the BARRIER_P from the loop test,
> Igor, so as to address the final ??? in the comment I add.  Narrowing
> the skipped notes to only the relevant post-call ones might make sense
> as well, but it's not quite as important IMHO.
> 
> Regstrapping with -fcompare-debug on stage3 host and target builds on
> x86_64- and i686-linux-gnu; ok to install?

Ok from me.

Am I correct the error you had was related to improper location information,
not the placement of the instruction? I will try to skip NOTE insns only.

Igor

> for  gcc/ChangeLog
> 
>   * config/i386/i386.c (rest_of_insert_endbranch): Use call loc
>   for its nop_endbr.
> ---
>  gcc/config/i386/i386.c |   20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index e323102cef59..8960b966b7fc 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -2609,21 +2609,25 @@ rest_of_insert_endbranch (void)
>   {
> if (INSN_P (insn) && GET_CODE (insn) == CALL_INSN)
>   {
> -   rtx_insn *next_insn = insn;
> +   if (find_reg_note (insn, REG_SETJMP, NULL) == NULL)
> + continue;
> +   /* Generate ENDBRANCH after CALL, which can return more than
> +  twice, setjmp-like functions.  */
> 
> +   /* Skip notes and debug insns that must be next to the
> +  call insn.  ??? This might skip a lot more than
> +  that...  ??? Skipping barriers and emitting code
> +  after them surely looks like a mistake; we probably
> +  won't ever hit it, for we'll hit BB_END first.  */
> +   rtx_insn *next_insn = insn;
> while ((next_insn != BB_END (bb))
> && (DEBUG_INSN_P (NEXT_INSN (next_insn))
> || NOTE_P (NEXT_INSN (next_insn))
> || BARRIER_P (NEXT_INSN (next_insn
>   next_insn = NEXT_INSN (next_insn);
> 
> -   /* Generate ENDBRANCH after CALL, which can return more than
> -  twice, setjmp-like functions.  */
> -   if (find_reg_note (insn, REG_SETJMP, NULL) != NULL)
> - {
> -   cet_eb = gen_nop_endbr ();
> -   emit_insn_after (cet_eb, next_insn);
> - }
> +   cet_eb = gen_nop_endbr ();
> +   emit_insn_after_setloc (cet_eb, next_insn, INSN_LOCATION
> (insn));
> continue;
>   }
> 
> 
> --
> Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member
> Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

[i386] PR83109 [CET] improper code generation for builtin_longjmp with -fcf-protection -mcet

[Tsimbalist, Igor V]

According to the description of  inssp instruction from Intel CET it adusts the 
shadow stack pointer (ssp) only by value in the range of [0..255]. As a number 
of adjustment could be greater than 255 there should be a loop generated to 
adjust ssp.

gcc/
* config/i386/i386.md: Add a loop with incssp.
* testsuite/gcc.target/i386/cet-sjlj-1.c: Fix test.
* testsuite/gcc.target/i386/cet-sjlj-4.c: Likewise.
---
gcc/config/i386/i386.md| 81 +++---
gcc/testsuite/gcc.target/i386/cet-sjlj-1.c |  2 +-
gcc/testsuite/gcc.target/i386/cet-sjlj-4.c |  2 +-

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index b871590..a14efc8 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -18394,15 +18394,16 @@
   "TARGET_SHSTK"
{
   rtx fp, lab, stack;
-  rtx jump, label, reg_adj, reg_ssp, reg_minus, mem_buf, tmp, clob;
+  rtx flags, jump, noadj_label, inc_label, loop_label;
+  rtx reg_adj, reg_ssp, mem_buf, tmp, clob;
   machine_mode sa_mode = STACK_SAVEAREA_MODE (SAVE_NONLOCAL);
   /* Adjust the shadow stack pointer (ssp) to the value saved in the
  jmp_buf.  The saving was done in the builtin_setjmp_setup.  */
   if (flag_cf_protection & CF_RETURN)
 {
-  /* Get current shadow stack pointer.  The code below will check if
-  SHSTK feature is enabled.  If it's not enabled RDSSP instruction
+  /* Get the current shadow stack pointer.  The code below will check if
+ SHSTK feature is enabled.  If it is not enabled the RDSSP 
instruction
is a NOP.  */
   reg_ssp = gen_reg_rtx (Pmode);
   emit_insn (gen_rtx_SET (reg_ssp, const0_rtx));
@@ -18410,40 +18411,84 @@
? gen_rdsspsi (reg_ssp, reg_ssp)
: gen_rdsspdi (reg_ssp, reg_ssp));
   mem_buf = gen_rtx_MEM (Pmode, plus_constant (Pmode, operands[0],
-   
  3 * GET_MODE_SIZE (Pmode))),
+   
 3 * GET_MODE_SIZE (Pmode)));
   /* Compare through substraction the saved and the current ssp to decide
if ssp has to be adjusted.  */
-  reg_minus = gen_reg_rtx (Pmode);
-  tmp = gen_rtx_SET (reg_minus, gen_rtx_MINUS (Pmode, reg_ssp, mem_buf));
+  reg_adj = gen_reg_rtx (Pmode);
+  tmp = gen_rtx_SET (reg_adj, gen_rtx_MINUS (Pmode, reg_ssp, mem_buf));
   clob = gen_rtx_CLOBBER (VOIDmode, gen_rtx_REG (CCmode, FLAGS_REG));
   tmp = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, tmp, clob));
   emit_insn (tmp);
-  /* Jump over adjustment code.  */
-  label = gen_label_rtx ();
-  tmp = gen_rtx_REG (CCmode, FLAGS_REG);
-  tmp = gen_rtx_EQ (VOIDmode, tmp, const0_rtx);
+  /* Compare and jump over adjustment code.  */
+  noadj_label = gen_label_rtx ();
+  flags = gen_rtx_REG (CCZmode, FLAGS_REG);
+  tmp = gen_rtx_EQ (VOIDmode, flags, const0_rtx);
   tmp = gen_rtx_IF_THEN_ELSE (VOIDmode, tmp,
-
gen_rtx_LABEL_REF (VOIDmode, label),
+   
gen_rtx_LABEL_REF (VOIDmode, noadj_label),
 pc_rtx);
   jump = emit_jump_insn (gen_rtx_SET (pc_rtx, tmp));
-  JUMP_LABEL (jump) = label;
+  JUMP_LABEL (jump) = noadj_label;
-  /* Adjust the ssp.  */
-  reg_adj = gen_reg_rtx (Pmode);
+  /* Compute the numebr of frames to adjust.  */
   tmp = gen_rtx_SET (reg_adj,
-  gen_rtx_LSHIFTRT (Pmode, 
negate_rtx (Pmode, reg_minus),
-   
  GEN_INT (3)));
+ gen_rtx_LSHIFTRT (Pmode, 
negate_rtx (Pmode, reg_adj),
+   
 GEN_INT ((Pmode == SImode)
+   
  ? 2
+   
  : 3)));
   clob = gen_rtx_CLOBBER (VOIDmode, gen_rtx_REG (CCmode, FLAGS_REG));
   tmp = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, tmp, clob));
   emit_insn (tmp);
+
+  /* Check if number of frames <= 255 so no loop is needed.  */
+  tmp = gen_rtx_COMPARE (CCmode, reg_adj, GEN_INT (255));
+  flags = gen_rtx_REG (CCmode, FLAGS_REG);
+  emit_insn (gen_rtx_SET (flags, tmp));
+
+  inc_label = gen_label_rtx ();
+  tmp = gen_rtx_LEU (VOIDmode, flags, const0_rtx);
+  tmp = gen_rtx_IF_THEN_ELSE (VOIDmode, tmp,
+   
gen_rtx_LABEL_REF (VOIDmode, inc_label),
+  

RE: [PATCH 08/22] Add Intel CET support for EH in libgcc.

[Tsimbalist, Igor V]

I propose the following changes. I do not have ia64 to test. Ok for trunk?

bash-4.2$ svn diff
Index: libgcc/config/cr16/unwind-cr16.c
===
--- libgcc/config/cr16/unwind-cr16.c(revision 254908)
+++ libgcc/config/cr16/unwind-cr16.c(working copy)
@@ -1567,7 +1567,7 @@
our caller.  */
 #if defined( __CR16C__ )

-#define uw_install_context(CURRENT, TARGET)\
+#define uw_install_context(CURRENT, TARGET, FRAMES)\
   do   \
 {  \
   long offset = uw_install_context_1 ((CURRENT), (TARGET));
\
@@ -1578,7 +1578,7 @@
 }  \
   while (0)
 #else
-#define uw_install_context(CURRENT, TARGET) \
+#define uw_install_context(CURRENT, TARGET, FRAMES) \
   do\
 {   \
   long offset = uw_install_context_1 ((CURRENT), (TARGET)); \
Index: libgcc/config/ia64/unwind-ia64.c
===
--- libgcc/config/ia64/unwind-ia64.c(revision 254908)
+++ libgcc/config/ia64/unwind-ia64.c(working copy)
@@ -2165,7 +2165,8 @@

 static void __attribute__((noreturn))
 uw_install_context (struct _Unwind_Context *current __attribute__((unused)),
-   struct _Unwind_Context *target)
+   struct _Unwind_Context *target,
+   unsigned long frames __attribute__((unused)))
 {
   unw_word ireg_buf[4], ireg_nat = 0, ireg_pr = 0;
   unw_word saved_lc;
Index: libgcc/config/xtensa/unwind-dw2-xtensa.c
===
--- libgcc/config/xtensa/unwind-dw2-xtensa.c(revision 254908)
+++ libgcc/config/xtensa/unwind-dw2-xtensa.c(working copy)
@@ -483,7 +483,7 @@
macro because __builtin_eh_return must be invoked in the context of
our caller.  */

-#define uw_install_context(CURRENT, TARGET) \
+#define uw_install_context(CURRENT, TARGET, FRAMES)
 \
   do\
 {   \
   long offset = uw_install_context_1 ((CURRENT), (TARGET));
 \
Index: libgcc/unwind-sjlj.c
===
--- libgcc/unwind-sjlj.c(revision 254908)
+++ libgcc/unwind-sjlj.c(working copy)
@@ -300,7 +300,8 @@

 static void __attribute__((noreturn))
 uw_install_context (struct _Unwind_Context *current __attribute__((unused)),
-struct _Unwind_Context *target)
+struct _Unwind_Context *target,
+   unsigned long frames __attribute__((unused)))
 {
   _Unwind_SjLj_SetContext (target->fc);
   longjmp (target->fc->jbuf, 1);


Igor

> -Original Message-
> From: Andreas Schwab [mailto:sch...@linux-m68k.org]
> Sent: Saturday, November 18, 2017 2:51 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: Jeff Law <l...@redhat.com>; gcc-patches@gcc.gnu.org; i...@airs.com
> Subject: Re: [PATCH 08/22] Add Intel CET support for EH in libgcc.
> 
> In file included from ../../../libgcc/config/ia64/unwind-ia64.c:2448:
> ../../../libgcc/unwind.inc: In function '_Unwind_RaiseException':
> ../../../libgcc/unwind.inc:140:3: error: too many arguments to function
> 'uw_install_context'
>uw_install_context (_context, _context, frames);
>^~
> ../../../libgcc/config/ia64/unwind-ia64.c:2167:1: note: declared here
>  uw_install_context (struct _Unwind_Context *current
> __attribute__((unused)),
>  ^~
> 
> Andreas.
> 
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

RE: [PATCH 08/22] Add Intel CET support for EH in libgcc.

[Tsimbalist, Igor V]

New patch is attached. The difference is that all newly introduced macro
are removed except of _Unwind_Frames_Extra macro. They are replaced
with new parameters and local variables.

Igor



0008-Add-Intel-CET-support-for-EH-in-libgcc.patch
Description: 0008-Add-Intel-CET-support-for-EH-in-libgcc.patch

RE: [PATCH 21/22] Add extra field to gtm_jmpbuf on x86 only

[Tsimbalist, Igor V]

> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Thursday, November 9, 2017 2:37 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: Jeff Law <l...@redhat.com>; gcc-patches@gcc.gnu.org;
> trie...@redhat.com; Jakub Jelinek <ja...@redhat.com>
> Subject: Re: [PATCH 21/22] Add extra field to gtm_jmpbuf on x86 only
> 
> On Wed, Nov 8, 2017 at 2:57 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> > On Wed, Nov 8, 2017 at 2:26 PM, Tsimbalist, Igor V
> > <igor.v.tsimbal...@intel.com> wrote:
> >>> -Original Message-
> >>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> >>> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> >>> Sent: Wednesday, November 8, 2017 7:31 PM
> >>> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> >>> patc...@gcc.gnu.org
> >>> Cc: trie...@redhat.com; Jakub Jelinek <ja...@redhat.com>
> >>> Subject: Re: [PATCH 21/22] Add extra field to gtm_jmpbuf on x86 only
> >>>
> >>> On 11/07/2017 09:22 AM, Tsimbalist, Igor V wrote:
> >>> > I decided to split my previous patch "Enable building libitm with Intel
> CET "
> >>> > into two different patches. The first patch will add a new field to 
> >>> > sjlj.S
> and
> >>> > target.h  files. The second one will add Intel CET support on the top of
> the
> >>> > first one. In this case the further changes for adding Intel CET support
> are
> >>> > seen clearly.
> >>> >
> >>> > Ok for trunk?
> >>> >
> >>>
> >>> [ ... snip ... ]
> >>>
> >>> >
> >>> >
> >>> > 0021-Add-extra-field-to-gtm_jmpbuf-on-x86-only.patch
> >>> >
> >>> >
> >>> > From a6361c78bf774f2b4dbeeaf4147c286cff4ae5a4 Mon Sep 17
> 00:00:00
> >>> 2001
> >>> > From: Igor Tsimbalist <igor.v.tsimbal...@intel.com>
> >>> > Date: Tue, 7 Nov 2017 17:00:24 +0300
> >>> > Subject: [PATCH 21/22] Add extra field to gtm_jmpbuf on x86 only
> >>> >
> >>> > Expand the gtm_jmpbuf structure by one word field to add
> >>> > Intel CET support further. The code in sjlj.S already
> >>> > allocates more space on the stack then gtm_jmpbuf needs.
> >>> > Use this extra space to absorb the new field.
> >>> >
> >>> > The structure is allocated on the stack in such a way
> >>> > that eip/rsp field is overlapped with return address on
> >>> > the stack. Locate the new field right before eip/rsp so
> >>> > code that accesses buffer fields relative to address of
> >>> > gtm_jmpbuf has its offsets unchanged.
> >>> >
> >>> > The libtool_VERSION is updated for x86 due to extending
> >>> > the gtm_jmpbuf structure.
> >>> >
> >>> > * libitm/config/x86/target.h: Add new field (ssp).
> >>> > * libitm/config/x86/sjlj.S: Change offsets.
> >>> > * libitm/configure.tgt: Update libtool_VERSION.
> >>> So if I understand correctly, given the desire to to have the eip/rip
> >>> field overlap with the return address on the stack offset changes are
> >>> inevitable if we add fields.
> >>
> >> Yes, that's exactly the case.
> >>
> >>> >  esac
> >>> > +
> >>> > +# Update libtool_VERSION since the size of struct gtm_jmpbuf is
> >>> > +# changed for x86.
> >>> > +case "${host}" in
> >>> > +
> >>> > +  # For x86, we use slots in the TCB head for most of our TLS.
> >>> > +  # The setup of those slots in beginTransaction can afford to
> >>> > +  # use the global-dynamic model.
> >>> > +  i[456]86-*-* | x86_64-*-*)
> >>> > +   libtool_VERSION=2:0:0
> >>> What's the plan for supporting existing code that may have linked
> >>> dynamically against libitm?
> >>
> >> This should just work.
> >>
> >>> One approach is to force the distros to carry the old libitm DSO.
> >>>
> >>> THe other would be to try and support both within the same DSO using
> >>> symbol versioning.  That would seem to imply that we'd need to the
> >>> before/after code to build that single library that supported both.
> >>>
> >>> Thoughts?  Jakub, 

RE: [PATCH 14/22] Enable building libsanitizer with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefiles for CET enabling.
 
Ok for trunk?

Igor

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:37 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Cc: ja...@redhat.com
> Subject: Re: [PATCH 14/22] Enable building libsanitizer with Intel CET
> 
> On 10/12/2017 02:27 PM, Tsimbalist, Igor V wrote:
> > Enable building libsanitizer with Intel CET options.
> >
> > libsanitizer/
> > * acinclude.m4: Add enable.m4 and cet.m4.
> > * Makefile.in: Regenerate.
> > * asan/Makefile.am: Update AM_CXXFLAGS.
> > * asan/Makefile.in: Regenerate.
> > * configure: Likewise.
> > * configure.ac: Set CET_FLAGS. Update EXTRA_CFLAGS,
> > * EXTRA_CXXFLAGS.
> > * interception/Makefile.am: Update AM_CXXFLAGS.
> > * interception/Makefile.in: Regenerate.
> > * libbacktrace/Makefile.am: Update AM_CFLAGS, AM_CXXFLAGS.
> > * libbacktrace/Makefile.in: Regenerate.
> > * lsan/Makefile.am: Update AM_CXXFLAGS.
> > * lsan/Makefile.in: Regenerate.
> > * sanitizer_common/Makefile.am: Update AM_CXXFLAGS.
> > * sanitizer_common/Makefile.in: Regenerate.
> > * tsan/Makefile.am: Update AM_CXXFLAGS.
> > * tsan/Makefile.in: Regenerate.
> > * ubsan/Makefile.am: Update AM_CXXFLAGS.
> > * ubsan/Makefile.in: Regenerate.
> >
> 
> Same comments as with libcilkrts.
> Jeff


0014-Enable-building-libsanitizer-with-Intel-CET.PATCH
Description: 0014-Enable-building-libsanitizer-with-Intel-CET.PATCH

RE: [PATCH 21/22] Add extra field to gtm_jmpbuf on x86 only

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Wednesday, November 8, 2017 7:31 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Cc: trie...@redhat.com; Jakub Jelinek <ja...@redhat.com>
> Subject: Re: [PATCH 21/22] Add extra field to gtm_jmpbuf on x86 only
> 
> On 11/07/2017 09:22 AM, Tsimbalist, Igor V wrote:
> > I decided to split my previous patch "Enable building libitm with Intel CET 
> > "
> > into two different patches. The first patch will add a new field to sjlj.S 
> > and
> > target.h  files. The second one will add Intel CET support on the top of the
> > first one. In this case the further changes for adding Intel CET support are
> > seen clearly.
> >
> > Ok for trunk?
> >
> 
> [ ... snip ... ]
> 
> >
> >
> > 0021-Add-extra-field-to-gtm_jmpbuf-on-x86-only.patch
> >
> >
> > From a6361c78bf774f2b4dbeeaf4147c286cff4ae5a4 Mon Sep 17 00:00:00
> 2001
> > From: Igor Tsimbalist <igor.v.tsimbal...@intel.com>
> > Date: Tue, 7 Nov 2017 17:00:24 +0300
> > Subject: [PATCH 21/22] Add extra field to gtm_jmpbuf on x86 only
> >
> > Expand the gtm_jmpbuf structure by one word field to add
> > Intel CET support further. The code in sjlj.S already
> > allocates more space on the stack then gtm_jmpbuf needs.
> > Use this extra space to absorb the new field.
> >
> > The structure is allocated on the stack in such a way
> > that eip/rsp field is overlapped with return address on
> > the stack. Locate the new field right before eip/rsp so
> > code that accesses buffer fields relative to address of
> > gtm_jmpbuf has its offsets unchanged.
> >
> > The libtool_VERSION is updated for x86 due to extending
> > the gtm_jmpbuf structure.
> >
> > * libitm/config/x86/target.h: Add new field (ssp).
> > * libitm/config/x86/sjlj.S: Change offsets.
> > * libitm/configure.tgt: Update libtool_VERSION.
> So if I understand correctly, given the desire to to have the eip/rip
> field overlap with the return address on the stack offset changes are
> inevitable if we add fields.

Yes, that's exactly the case.

> >  esac
> > +
> > +# Update libtool_VERSION since the size of struct gtm_jmpbuf is
> > +# changed for x86.
> > +case "${host}" in
> > +
> > +  # For x86, we use slots in the TCB head for most of our TLS.
> > +  # The setup of those slots in beginTransaction can afford to
> > +  # use the global-dynamic model.
> > +  i[456]86-*-* | x86_64-*-*)
> > +   libtool_VERSION=2:0:0
> What's the plan for supporting existing code that may have linked
> dynamically against libitm?

This should just work.

> One approach is to force the distros to carry the old libitm DSO.
> 
> THe other would be to try and support both within the same DSO using
> symbol versioning.  That would seem to imply that we'd need to the
> before/after code to build that single library that supported both.
> 
> Thoughts?  Jakub, any interest in chiming in here?

My thought is that the buffer is encapsulated in the library, only sjlj.S
functions allocate the buffer and access the fields of the buffer, it's
sort of a black box. If an app loads the library it will work with the
buffer through the library's functions from sjlj.S , which are compiled
together.

Igor

> jeff
> > +   ;;
> > +esac
> > -- 1.8.3.1
> >

RE: [PATCH 07/22] Enable building libgcc with CET options.

[Tsimbalist, Igor V]

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, November 8, 2017 6:21 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; Joseph Myers
> <jos...@codesourcery.com>; gcc-patches@gcc.gnu.org; i...@airs.com
> Subject: Re: [PATCH 07/22] Enable building libgcc with CET options.
> 
> On 10/31/2017 05:29 AM, Tsimbalist, Igor V wrote:
> > The revised patch is attached. The differences are in what options are
> defined and propagated to Makefile for CET enabling, also needed asm files
> are updated.
> >
> [ ... ]
> 
> >
> > 0007-Enable-building-libgcc-with-CET-options.patch
> >
> >
> > From df923f7e0ebee1f10136bb64f9c723f2d58f8f2a Mon Sep 17 00:00:00
> 2001
> > From: Igor Tsimbalist <igor.v.tsimbal...@intel.com>
> > Date: Fri, 27 Oct 2017 15:44:56 +0300
> > Subject: [PATCH 07/21] Enable building libgcc with CET options
> >
> > Enable building libgcc with CET options by default on Linux/x86 if
> > binutils supports CET v2.0.  It can be disabled with --disable-cet.
> > It is an error to configure GCC with --enable-cet if bintuiils doesn't
> > support CET v2.0.
> >
> > ENDBR is added to __morestack_large_model since it is called indirectly.
> >
> > config/
> > * cet.m4: New file.
> >
> > gcc/
> > * config.gcc (extra_headers): Add cet.h for x86 targets.
> > * config/i386/cet.h: New file.
> > * doc/install.texi: Add --enable-cet/--disable-cet.
> >
> > libgcc/
> > * Makefile.in (configure_deps): Add $(srcdir)/../config/cet.m4.
> > (CET_FLAGS): New.
> > * config/i386/morestack.S: Include .
> > (__morestack_large_model): Add _CET_ENDBR at function entrance.
> > * config/i386/resms64.h: Include .
> > * config/i386/resms64f.h: Likewise.
> > * config/i386/resms64fx.h: Likewise.
> > * config/i386/resms64x.h: Likewise.
> > * config/i386/savms64.h: Likewise.
> > * config/i386/savms64f.h: Likewise.
> > * config/i386/t-linux (HOST_LIBGCC2_CFLAGS): Add $(CET_FLAGS).
> > (CRTSTUFF_T_CFLAGS): Likewise.
> > * configure.ac: Include ../config/cet.m4.
> > Set and substitute CET_FLAGS.
> > * configure: Regenerated.
> So the question I have WRT this patch is the default setting.  If I
> understand it correctly, if the assembler supports the appropriate
> insns, then we enable building target libraries with CET by default.

That's right.

> These libraries continue to work on older systems without CET
> capabilities because the CET specific instructions are interpreted as
> NOPs on older hardware, right?

That's correct. One specific note though. The endbr and rdssp instructions
will be treated as NOPs. Incssp instruction generated by the compiler or
used in the library will be guarded not to be executed if CET features are
not enabled.

> What about cases where we're running on CET capable hardware, the main
> program gets compiled without CET, but links against a libgcc with CET.
> What happens in that case?

All object files and libraries must have CET property set to make the whole
application to be CET capable. In your case the program will not be CET
capable.

Igor

> What triggers the use of CET vs interpreting those instructions as NOPs
>
> I don't doubt y'all have already thought about these cases.  I just want
> to make sure that I understand them and the implications before I ack
> this patch.
> 
> Jeff

RE: [PATCH 08/22] Add Intel CET support for EH in libgcc.

[Tsimbalist, Igor V]

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, November 8, 2017 8:06 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Cc: i...@airs.com
> Subject: Re: [PATCH 08/22] Add Intel CET support for EH in libgcc.
> 
> On 11/04/2017 06:43 AM, Tsimbalist, Igor V wrote:
> >> -Original Message-
> >> From: Jeff Law [mailto:l...@redhat.com]
> >> Sent: Tuesday, October 31, 2017 5:49 AM
> >> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> >> patc...@gcc.gnu.org
> >> Cc: i...@airs.com
> >> Subject: Re: [PATCH 08/22] Add Intel CET support for EH in libgcc.
> >>
> >> On 10/12/2017 01:56 PM, Tsimbalist, Igor V wrote:
> >>> Control-flow Enforcement Technology (CET), published by Intel,
> Introduces
> >>> the Shadow Stack feature, which ensures a return from a function is
> done
> >>> to exactly the same location from where the function was called. When
> EH
> >>> is present the control-flow transfer may skip some stack frames and the
> >>> shadow stack has to be adjusted not to signal a violation of a
> >>> control-flow transfer. It's done by counting a number of skipping frames
> >>> and adjusting shadow stack pointer by this number.
> >>>
> >>> gcc/
> >>>   * config/i386/i386.c (ix86_expand_epilogue): Change simple
> >>>   return to indirect jump for EH return. Change explicit 'false'
> >>>   argument in pro_epilogue_adjust_stack with a value of
> >>>   flag_cf_protection.
> >>>   * config/i386/i386.md (simple_return_indirect_internal): Remove
> >>>   SImode restriction to support 64-bit.
> >>>
> >>> libgcc/
> >>>   * config/i386/linux-unwind.h: Include
> >>>   config/i386/shadow-stack-unwind.h.
> >>>   * config/i386/shadow-stack-unwind.h: New file.
> >>>   * unwind-dw2.c: (uw_install_context): Add a FRAMES argument and
> >>>   pass it to _Unwind_Frames_Extra.
> >>>   * unwind-generic.h (FRAMES_P_DECL): New.
> >>>   (FRAMES_VAR): Likewise.
> >>>   (FRAMES_VAR_P): Likewise.
> >>>   (FRAMES_VAR_DECL): Likewise.
> >>>   (FRAMES_VAR_DECL_1): Likewise.
> >>>   (FRAMES_VAR_INC): Likewise.
> >>>   (FRAMES_P_UPDATE): Likewise.
> >>>   (_Unwind_Frames_Extra): Likewise.
> >>>   * unwind.inc (_Unwind_RaiseException_Phase2): Use
> >> FRAMES_P_DECL,
> >>>   FRAMES_VAR_DECL_1, FRAMES_VAR_INC and FRAMES_P_UPDATE.
> >>>   (_Unwind_RaiseException): Use FRAMES_VAR_DECL,
> >> FRAMES_VAR_P and
> >>>   FRAMES_VAR.
> >>>   (_Unwind_ForcedUnwind_Phase2): Use FRAMES_P_DECL,
> >>>   FRAMES_VAR_DECL_1, FRAMES_VAR_INC, FRAMES_P_UPDATE.
> >>>   (_Unwind_ForcedUnwind): Use FRAMES_VAR_DECL,
> >> FRAMES_VAR_P and
> >>>   FRAMES_VAR.
> >>>   (_Unwind_Resume): Use FRAMES_VAR_DECL, FRAMES_VAR_P and
> >>>   FRAMES_VAR.
> >>>   (_Unwind_Resume_or_Rethrow): Use FRAMES_VAR_DECL,
> >> FRAMES_VAR_P
> >>>   and FRAMES_VAR.
> >>>
> >>> Igor
> >>>
> >>>
> >>>
> >>> 0008-Add-Intel-CET-support-for-EH-in-libgcc.patch
> >>>
> >>>
> >>> From 16eb1d0d9239e039fba28f1ae71762f19061b157 Mon Sep 17
> 00:00:00
> >> 2001
> >>> From: Igor Tsimbalist <igor.v.tsimbal...@intel.com>
> >>> Date: Wed, 19 Jul 2017 03:04:46 +0300
> >>> Subject: [PATCH 08/22] Add Intel CET support for EH in libgcc.
> >>>
> >>> Control-flow Enforcement Technology (CET), published by Intel,
> >>> introduces
> >>> the Shadow Stack feature, which ensures a return from a function is
> done
> >>> to exactly the same location from where the function was called. When
> EH
> >>> is present the control-flow transfer may skip some stack frames and the
> >>> shadow stack has to be adjusted not to signal a violation of a
> >>> control-flow transfer. It's done by counting a number of skiping frames
> >>> and adjasting shadow stack pointer by this number.
> >>>
> >>> Having new semantic of the 'ret' instruction if CET is supported in HW
> >>> the 'ret' instruction cannot be generated in ix86_expand_epilogue when
> >>> we are returning after EH is processed. Added a code in
> >>> ix86_expand_epilogue to adjust Shadow Stack pointe

RE: [PATCH 21/22] Add extra field to gtm_jmpbuf on x86 only

[Tsimbalist, Igor V]

Igor


> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Wednesday, November 8, 2017 7:18 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: Jeff Law <l...@redhat.com>; gcc-patches@gcc.gnu.org;
> trie...@redhat.com
> Subject: Re: [PATCH 21/22] Add extra field to gtm_jmpbuf on x86 only
> 
> On Tue, Nov 7, 2017 at 8:22 AM, Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com> wrote:
> > I decided to split my previous patch "Enable building libitm with Intel CET 
> > "
> > into two different patches. The first patch will add a new field to sjlj.S 
> > and
> > target.h  files. The second one will add Intel CET support on the top of the
> > first one. In this case the further changes for adding Intel CET support are
> > seen clearly.
> >
> > Ok for trunk?
> >
> 
> libitm/configure.tgt should check ${target} like the other places:
> 
> +# Update libtool_VERSION since the size of struct gtm_jmpbuf is
> +# changed for x86.
> +case "${host}" in
> 
> Did these come from cut and paste?
> 
> +  # For x86, we use slots in the TCB head for most of our TLS.
> +  # The setup of those slots in beginTransaction can afford to
> +  # use the global-dynamic model.
> 
> I think the whole thing should be:
> 
> case "${target}" in
>   # Update libtool_VERSION since the size of struct gtm_jmpbuf is
>   # changed for x86.
>   i[456]86-*-* | x86_64-*-*)
> libtool_VERSION=2:0:0
> ;;
> esac

There was a feedback from Joseph (email attached) with the comment about
similar case in cet.m4:

> This file is checking $target.  That's only ever appropriate in 
directories
> building compilers and similar tools; target library directories 
should check
> $host, as the host for target libraries is the target for the 
compiler.

Igor

> 
> 
> 
> --
> H.J.
--- Begin Message ---
> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Thursday, October 12, 2017 10:36 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: gcc-patches@gcc.gnu.org; Jeff Law <l...@redhat.com>; i...@airs.com
> Subject: Re: [PATCH 07/22] Enable building libgcc with CET options.
>
> On Thu, 12 Oct 2017, Tsimbalist, Igor V wrote:
>
> > Enable building libgcc with CET options by default on Linux/x86 if
> > binutils supports CET v2.0.
> > It can be disabled with --disable-cet.  It is an error to configure
> > GCC with --enable-cet if bintuiils doesn't support CET v2.0.
> >
> > config/
> > * cet.m4: New file
>
> This file is checking $target.  That's only ever appropriate in directories
> building compilers and similar tools; target library directories should check
> $host, as the host for target libraries is the target for the compiler.

Fixed.

> This file has a comment
>
> > +dnl GCC_CET_LIBRARY
> > +dnl(SHELL-CODE_HANDLER)
>
> which doesn't seem to match the subsequent definition of GCC_CET_FLAGS.

Fixed.

> I don't see any documentation of the new configure option.  I'd expect the
> first patch adding such an option to document it in install.texi, and then
> subsequent patches to update that documentation if those patches extend
> the option to cover more things.

Added the description of this configure option to install.texi.

The updated patch is attached.

Igor

> --
> Joseph S. Myers
> jos...@codesourcery.com


0007-Enable-building-libgcc-with-CET-options.patch
Description: 0007-Enable-building-libgcc-with-CET-options.patch
--- End Message ---

[PATCH 22/22] Enable building libitm with Intel CET

[Tsimbalist, Igor V]

Enable building libitm with Intel CET. The patch is based on previous patch 
[PATCH 21/22] Add extra field to gtm_jmpbuf on x86 only.

Ok for trunk?

Igor



0022-Enable-building-libitm-with-Intel-CET.PATCH
Description: 0022-Enable-building-libitm-with-Intel-CET.PATCH

[PATCH 21/22] Add extra field to gtm_jmpbuf on x86 only

[Tsimbalist, Igor V]

I decided to split my previous patch "Enable building libitm with Intel CET "
into two different patches. The first patch will add a new field to sjlj.S and
target.h  files. The second one will add Intel CET support on the top of the
first one. In this case the further changes for adding Intel CET support are
seen clearly.

Ok for trunk?

Igor


> -Original Message-
> From: Tsimbalist, Igor V
> Sent: Tuesday, October 31, 2017 5:30 PM
> To: Jeff Law <l...@redhat.com>; gcc-patches@gcc.gnu.org
> Cc: trie...@redhat.com; Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Subject: RE: [PATCH 21/22] Enable building libitm with Intel CET
> 
> > -Original Message-
> > From: Jeff Law [mailto:l...@redhat.com]
> > Sent: Tuesday, October 31, 2017 12:21 AM
> > To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> > patc...@gcc.gnu.org
> > Cc: trie...@redhat.com
> > Subject: Re: [PATCH 21/22] Enable building libitm with Intel CET
> >
> > On 10/12/2017 03:21 PM, Tsimbalist, Igor V wrote:
> > > Enable building libitm with Intel CET options.
> > >
> > > libitm/
> > >   * Makefile.in: Regenerate.
> > >   * acinclude.m4: Add enable.m4 and cet.m4.
> > >   * config/x86/sjlj.S
> > >   (_ITM_beginTransaction): Save Shadow Stack pointer.
> > >   (GTM_longjmp): Restore Shadow Stack pointer.
> > >   * config/x86/target.h (struct gtm_jmpbuf):
> > >   Add Shadow Stack pointer.
> > >   * configure: Regenerate.
> > >   * configure.ac: Set CET_FLAGS. Update XCFLAGS, libtool_VERSION.
> > >   * testsuite/Makefile.in: Regenerate.
> > >
> > >   * config/cet.m4: Define ENABLE_CET_COMPATIBILITY. Set
> > >   enable_cet_compatibility.
> > >
> > Would it make sense to avoid having different sizes of gtm_jmpbuf by
> > simply having the ssp slot always defined, even if we're not using it?
> 
> Yes, it make sense. We can do it for x86 configuration. In that case the
> conditional code will be limited to Shadow Stack pointer read/write.
> 
> > Along the same lines, would it make sense to have that field at the end
> > of the structure so that the amount of conditional code in in sjlj.S is
> > minimized (ie, all the offests are the same, so in the CET case you just
> > have a single extra store).
> 
> The comments says the buffer is specially located in such a way that eip/rip
> field overlap with  a return address on the stack. That means the field can be
> added anywhere before eip/rip and in turn the offsets will change.
> 
> I will re-implement the fixes with adding the new field for x86 only.
> 
> Igor
> 
> >
> > Jeff



0021-Add-extra-field-to-gtm_jmpbuf-on-x86-only.patch
Description: 0021-Add-extra-field-to-gtm_jmpbuf-on-x86-only.patch

RE: [PATCH 08/22] Add Intel CET support for EH in libgcc.

[Tsimbalist, Igor V]

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, October 31, 2017 5:49 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Cc: i...@airs.com
> Subject: Re: [PATCH 08/22] Add Intel CET support for EH in libgcc.
> 
> On 10/12/2017 01:56 PM, Tsimbalist, Igor V wrote:
> > Control-flow Enforcement Technology (CET), published by Intel, Introduces
> > the Shadow Stack feature, which ensures a return from a function is done
> > to exactly the same location from where the function was called. When EH
> > is present the control-flow transfer may skip some stack frames and the
> > shadow stack has to be adjusted not to signal a violation of a
> > control-flow transfer. It's done by counting a number of skipping frames
> > and adjusting shadow stack pointer by this number.
> >
> > gcc/
> > * config/i386/i386.c (ix86_expand_epilogue): Change simple
> > return to indirect jump for EH return. Change explicit 'false'
> > argument in pro_epilogue_adjust_stack with a value of
> > flag_cf_protection.
> > * config/i386/i386.md (simple_return_indirect_internal): Remove
> > SImode restriction to support 64-bit.
> >
> > libgcc/
> > * config/i386/linux-unwind.h: Include
> > config/i386/shadow-stack-unwind.h.
> > * config/i386/shadow-stack-unwind.h: New file.
> > * unwind-dw2.c: (uw_install_context): Add a FRAMES argument and
> > pass it to _Unwind_Frames_Extra.
> > * unwind-generic.h (FRAMES_P_DECL): New.
> > (FRAMES_VAR): Likewise.
> > (FRAMES_VAR_P): Likewise.
> > (FRAMES_VAR_DECL): Likewise.
> > (FRAMES_VAR_DECL_1): Likewise.
> > (FRAMES_VAR_INC): Likewise.
> > (FRAMES_P_UPDATE): Likewise.
> > (_Unwind_Frames_Extra): Likewise.
> > * unwind.inc (_Unwind_RaiseException_Phase2): Use
> FRAMES_P_DECL,
> > FRAMES_VAR_DECL_1, FRAMES_VAR_INC and FRAMES_P_UPDATE.
> > (_Unwind_RaiseException): Use FRAMES_VAR_DECL,
> FRAMES_VAR_P and
> > FRAMES_VAR.
> > (_Unwind_ForcedUnwind_Phase2): Use FRAMES_P_DECL,
> > FRAMES_VAR_DECL_1, FRAMES_VAR_INC, FRAMES_P_UPDATE.
> > (_Unwind_ForcedUnwind): Use FRAMES_VAR_DECL,
> FRAMES_VAR_P and
> > FRAMES_VAR.
> > (_Unwind_Resume): Use FRAMES_VAR_DECL, FRAMES_VAR_P and
> > FRAMES_VAR.
> > (_Unwind_Resume_or_Rethrow): Use FRAMES_VAR_DECL,
> FRAMES_VAR_P
> > and FRAMES_VAR.
> >
> > Igor
> >
> >
> >
> > 0008-Add-Intel-CET-support-for-EH-in-libgcc.patch
> >
> >
> > From 16eb1d0d9239e039fba28f1ae71762f19061b157 Mon Sep 17 00:00:00
> 2001
> > From: Igor Tsimbalist <igor.v.tsimbal...@intel.com>
> > Date: Wed, 19 Jul 2017 03:04:46 +0300
> > Subject: [PATCH 08/22] Add Intel CET support for EH in libgcc.
> >
> > Control-flow Enforcement Technology (CET), published by Intel,
> > introduces
> > the Shadow Stack feature, which ensures a return from a function is done
> > to exactly the same location from where the function was called. When EH
> > is present the control-flow transfer may skip some stack frames and the
> > shadow stack has to be adjusted not to signal a violation of a
> > control-flow transfer. It's done by counting a number of skiping frames
> > and adjasting shadow stack pointer by this number.
> >
> > Having new semantic of the 'ret' instruction if CET is supported in HW
> > the 'ret' instruction cannot be generated in ix86_expand_epilogue when
> > we are returning after EH is processed. Added a code in
> > ix86_expand_epilogue to adjust Shadow Stack pointer and to generate an
> > indirect jump instead of 'ret'. As sp register is used during this
> > adjustment thus the argument in pro_epilogue_adjust_stack is changed
> > to update cfa_reg based on whether control-flow instrumentation is set.
> > Without updating the cfa_reg field there is an assert later in dwarf2
> > pass related to mismatch the stack register and cfa_reg value.
> >
> > gcc/
> > * config/i386/i386.c (ix86_expand_epilogue): Change simple
> > return to indirect jump for EH return. Change explicit 'false'
> > argument in pro_epilogue_adjust_stack with a value of
> > flag_cf_protection.
> > * config/i386/i386.md (simple_return_indirect_internal): Remove
> > SImode restriction to support 64-bit.
> >
> > libgcc/
> > * config/i386/linux-unwind.h: Include
> > config/i386/shadow-stack-unwind.h.
> > * config/i386/shadow-stack-unwin

RE: [PATCH 21/22] Enable building libitm with Intel CET

[Tsimbalist, Igor V]

Actually I did changes to add the new field for linux under ifdef __linux__.

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, October 31, 2017 12:21 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Cc: trie...@redhat.com
> Subject: Re: [PATCH 21/22] Enable building libitm with Intel CET
> 
> On 10/12/2017 03:21 PM, Tsimbalist, Igor V wrote:
> > Enable building libitm with Intel CET options.
> >
> > libitm/
> > * Makefile.in: Regenerate.
> > * acinclude.m4: Add enable.m4 and cet.m4.
> > * config/x86/sjlj.S
> > (_ITM_beginTransaction): Save Shadow Stack pointer.
> > (GTM_longjmp): Restore Shadow Stack pointer.
> > * config/x86/target.h (struct gtm_jmpbuf):
> > Add Shadow Stack pointer.
> > * configure: Regenerate.
> > * configure.ac: Set CET_FLAGS. Update XCFLAGS, libtool_VERSION.
> > * testsuite/Makefile.in: Regenerate.
> >
> > * config/cet.m4: Define ENABLE_CET_COMPATIBILITY. Set
> > enable_cet_compatibility.
> >
> Would it make sense to avoid having different sizes of gtm_jmpbuf by
> simply having the ssp slot always defined, even if we're not using it?

Yes, it make sense. We can do it for x86 configuration. In that case the
conditional code will be limited to Shadow Stack pointer read/write.

> Along the same lines, would it make sense to have that field at the end
> of the structure so that the amount of conditional code in in sjlj.S is
> minimized (ie, all the offests are the same, so in the CET case you just
> have a single extra store).

The comments says the buffer is specially located in such a way that eip/rip
field overlap with  a return address on the stack. That means the field can be
added anywhere before eip/rip and in turn the offsets will change.

I will re-implement the fixes with adding the new field for x86 only.

Igor

> 
> Jeff

RE: [PATCH 07/22] Enable building libgcc with CET options.

[Tsimbalist, Igor V]

Ok, just did it :)

Igor


> -Original Message-
> From: Andreas Schwab [mailto:sch...@linux-m68k.org]
> Sent: Tuesday, October 31, 2017 4:00 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: Joseph Myers <jos...@codesourcery.com>; gcc-patches@gcc.gnu.org;
> Jeff Law <l...@redhat.com>; i...@airs.com
> Subject: Re: [PATCH 07/22] Enable building libgcc with CET options.
> 
> On Okt 31 2017, "Tsimbalist, Igor V" <igor.v.tsimbal...@intel.com> wrote:
> 
> > Fixed.
> >
> > -  i[34567]86-*-linux* | x86_64-*-linux*)
> > +  i[[34567]]86-*-linux* | x86_64-*-linux*)
> 
> Don't forget to regenerate all configure scripts.
> 
> Andreas.
> 
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

RE: [PATCH 07/22] Enable building libgcc with CET options.

[Tsimbalist, Igor V]

Fixed.

-  i[34567]86-*-linux* | x86_64-*-linux*)
+  i[[34567]]86-*-linux* | x86_64-*-linux*)

Igor


> -Original Message-
> From: Andreas Schwab [mailto:sch...@linux-m68k.org]
> Sent: Tuesday, October 31, 2017 2:30 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: Joseph Myers <jos...@codesourcery.com>; gcc-patches@gcc.gnu.org;
> Jeff Law <l...@redhat.com>; i...@airs.com
> Subject: Re: [PATCH 07/22] Enable building libgcc with CET options.
> 
> On Okt 31 2017, "Tsimbalist, Igor V" <igor.v.tsimbal...@intel.com> wrote:
> 
> > diff --git a/config/cet.m4 b/config/cet.m4
> > new file mode 100644
> > index 000..c903791
> > --- /dev/null
> > +++ b/config/cet.m4
> > @@ -0,0 +1,40 @@
> > +dnl
> > +dnl GCC_CET_FLAGS
> > +dnl(SHELL-CODE_HANDLER)
> > +dnl
> > +AC_DEFUN([GCC_CET_FLAGS],[dnl
> > +GCC_ENABLE(cet, default, ,[enable Intel CET in target libraries],
> > +  permit yes|no|default)
> > +case "$host" in
> > +  i[34567]86-*-linux* | x86_64-*-linux*)
> 
> Missing quoting around [...].
> 
> Andreas.
> 
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

RE: [PATCH 20/22] Enable building libobjc with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:43 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH 20/22] Enable building libobjc with Intel CET
> 
> On 10/12/2017 03:19 PM, Tsimbalist, Igor V wrote:
> > Enable building libobjc with Intel CET options.
> >
> > libobjc/
> > * Makefile.in: Regenerate.
> > * aclocal.m4: Likeiwse.
> > * configure: Likewise.
> > * configure.ac: Set CET_FLAGS. Update XCFLAGS.
> >
> 
> 
> Same comments as the libcilkrts changes.
> 
> Jeff


0020-Enable-building-libobjc-with-Intel-CET.PATCH
Description: 0020-Enable-building-libobjc-with-Intel-CET.PATCH

RE: [PATCH 19/22] Enable building libgfortran with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:43 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH 19/22] Enable building libgfortran with Intel CET
> 
> On 10/12/2017 03:17 PM, Tsimbalist, Igor V wrote:
> > Enable building libgfortran with Intel CET options.
> >
> > libgfortran/
> > * acinclude.m4: Add enable.m4, cet.m4.
> > * configure: Regenerate.
> > * configure.ac: Set CET_FLAGS. Update AM_FCFLAGS, AM_CFLAGS,
> > CFLAGS.
> >
> 
> Same comments as the libcilkrts changes.
> 
> Jeff


0019-Enable-building-libgfortran-with-Intel-CET.PATCH
Description: 0019-Enable-building-libgfortran-with-Intel-CET.PATCH

RE: [PATCH 18/22] Enable building libmpx with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Wednesday, October 18, 2017 1:42 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Cc: enkovich@gmail.com
> Subject: Re: [PATCH 18/22] Enable building libmpx with Intel CET
> 
> On 10/12/2017 02:36 PM, Tsimbalist, Igor V wrote:
> > Enable building libmpx with Intel CET options.
> >
> > libmpx/
> > * Makefile.in: Regenerate.
> > * acinclude.m4: Add enable.m4 and cet.m4.
> > * configure: Regenerate.
> > * configure.ac: Set CET_FLAGS. Update XCFLAGS.
> > * mpxrt/Makefile.am: Update libmpx_la_CFLAGS.
> > * mpxrt/Makefile.in: Regenerate.
> > * mpxwrap/Makefile.am: Add AM_CFLAGS. Update
> > * libmpxwrappers_la_CFLAGS.
> > * mpxwrap/Makefile.in: Regenerate.
> >
> 
> 
> Same comments as the libcilkrts changes.
> 
> Jeff


0018-Enable-building-libmpx-with-Intel-CET.PATCH
Description: 0018-Enable-building-libmpx-with-Intel-CET.PATCH

RE: [PATCH 17/22] Enable building libquadmath with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:41 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Cc: ja...@redhat.com
> Subject: Re: [PATCH 17/22] Enable building libquadmath with Intel CET
> 
> On 10/12/2017 02:34 PM, Tsimbalist, Igor V wrote:
> > Enable building libquadmath with Intel CET options.
> >
> > libquadmath/
> > * Makefile.am: Update AM_CFLAGS.
> > * Makefile.in: Regenerate:
> > * acinclude.m4: Add enable.m4 and cet.m4.
> > * configure: Regenerate.
> > * configure.ac: Set CET_FLAGS. Update XCFLAGS.
> >
> 
> Same comments as the libcilkrts changes.
> 
> Jeff


0017-Enable-building-libquadmath-with-Intel-CET.PATCH
Description: 0017-Enable-building-libquadmath-with-Intel-CET.PATCH

RE: [PATCH 16/22] Enable building libssp with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:38 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH 16/22] Enable building libssp with Intel CET
> 
> On 10/12/2017 02:31 PM, Tsimbalist, Igor V wrote:
> > Enable building libssp with Intel CET options.
> >
> > libssp/
> > * Makefile.am: Update AM_CFLAGS.
> > * Makefile.in: Regenerate.
> > * configure: Likewise.
> > * aclocal.m4: Likewise.
> > * configure.ac: Set CET_FLAGS. Update XCFLAGS.
> >
> 
> Same comments as with libcilkrts.
> Jeff


0016-Enable-building-libssp-with-Intel-CET.PATCH
Description: 0016-Enable-building-libssp-with-Intel-CET.PATCH

RE: [PATCH 15/22] Enable building libvtv with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:38 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Cc: cmt...@google.com
> Subject: Re: [PATCH 15/22] Enable building libvtv with Intel CET
> 
> On 10/12/2017 02:29 PM, Tsimbalist, Igor V wrote:
> > Enable building libvtv with Intel CET options.
> >
> > libvtv/
> > * acinclude.m4: Add enable.m4 and cet.m4.
> > * libvtv/configure: Regenerate.
> > * libvtv/configure.ac: Set CET_FLAGS. Update XCFLAGS.
> Same comments as with libcilkrts.
> Jeff
> 



0015-Enable-building-libvtv-with-Intel-CET.PATCH
Description: 0015-Enable-building-libvtv-with-Intel-CET.PATCH

RE: [PATCH 13/22] Enable building libstdc++-v3 with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Tsimbalist, Igor V
> Sent: Friday, October 13, 2017 2:09 PM
> To: gcc-patches@gcc.gnu.org; libstd...@gcc.gnu.org
> Cc: Jeff Law <l...@redhat.com>; Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com>
> Subject: RE: [PATCH 13/22] Enable building libstdc++-v3 with Intel CET
> 
> Added libstd...@gcc.gnu.org
> 
> 
> > -----Original Message-
> > From: Tsimbalist, Igor V
> > Sent: Thursday, October 12, 2017 10:24 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Jeff Law <l...@redhat.com>; jwak...@redhat.com; Tsimbalist, Igor V
> > <igor.v.tsimbal...@intel.com>
> > Subject: [PATCH 13/22] Enable building libstdc++-v3 with Intel CET
> >
> > Enable building libstdc++v3 with CET options.
> >
> > libstdc++-v3/
> > * acinclude.m4: Add cet.m4.
> > * configure.ac: Set CET_FLAGS. Update EXTRA_CFLAGS.
> > * libsupc++/Makefile.am: Add EXTRA_CFLAGS.
> > * Makefile.in: Regenerate.
> > * configure: Likewise.
> > * doc/Makefile.in: Likewise.
> > * include/Makefile.in: Likewise.
> > * libsupc++/Makefile.in: Likewise.
> > * po/Makefile.in: Likewise.
> > * python/Makefile.in: Likewise.
> > * src/Makefile.in: Likewise.
> > * src/c++11/Makefile.in: Likewise.
> > * src/c++98/Makefile.in: Likewise.
> > * src/filesystem/Makefile.in: Likewise.
> > * testsuite/Makefile.in: Likewise.



0013-Enable-building-libstdc-v3-with-Intel-CET.PATCH
Description: 0013-Enable-building-libstdc-v3-with-Intel-CET.PATCH

RE: [PATCH 12/22] Enable building libgomp with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:36 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Cc: ja...@redhat.com
> Subject: Re: [PATCH 12/22] Enable building libgomp with Intel CET
> 
> On 10/12/2017 02:20 PM, Tsimbalist, Igor V wrote:
> > Enable building libgomp with CET options.
> >
> > libgomp/
> > * configure.ac: Set CET_FLAGS, update XCFLAGS and FCFLAGS.
> > * acinclude.m4: Add cet.m4.
> > * configure: Regenerate.
> > * Makefile.in: Likewise.
> > * testsuite/Makefile.in: Likewise
> >
> 
> Same comments as with libcilkrts.
> Jeff


0012-Enable-building-libgomp-with-Intel-CET.PATCH
Description: 0012-Enable-building-libgomp-with-Intel-CET.PATCH

RE: [PATCH 11/22] Enable building libatomic with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.
 
Ok for trunk?

Igor


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:35 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH 11/22] Enable building libatomic with Intel CET
> 
> On 10/12/2017 02:18 PM, Tsimbalist, Igor V wrote:
> > Enable building libatomic with CET options.
> >
> > libatomic/
> > * configure.ac: Set CET_FLAGS, update XCFLAGS.
> > * acinclude.m4: Add cet.m4 and enable.m4.
> > * configure: Regenerate.
> > * Makefile.in: Likewise.
> > * testsuite/Makefile.in: Likewise.
> >
> Same comments as with libcilkrts.
> Jeff


0011-Enable-building-libatomic-with-Intel-CET.PATCH
Description: 0011-Enable-building-libatomic-with-Intel-CET.PATCH

RE: [PATCH 10/22] Enable building libcilkrts with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling.

Ok for trunk?

Igor


> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Wednesday, October 18, 2017 1:34 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH 10/22] Enable building libcilkrts with Intel CET
> 
> On 10/12/2017 02:13 PM, Tsimbalist, Igor V wrote:
> > Enable building libcilkrts with CET options.
> >
> > libcilkrts/
> > * Makefile.am: Add AM_CXXFLAGS and XCXXFLAGS.
> > * configure.ac: Set CET_FLAGS, update XCFLAGS, XCXXFLAGS.
> > * Makefile.in: Regenerate.
> > * aclocal.m4: Likewise.
> > * configure: Likewise.
> >
> So like the other patches in this space, the inclusion of cet.h seems
> wrong.  I don't see why this should be needed here.
> 
> It's OK with that bit removed and once any prereqs are OK'd.
> 
> jeff


0010-Enable-building-libcilkrts-with-Intel-CET.PATCH
Description: 0010-Enable-building-libcilkrts-with-Intel-CET.PATCH

RE: [PATCH 09/22] Enable building libbacktrace with Intel CET

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling. -iclude option is dropped, each 
needed asm file is processed separately.

Igor


> -Original Message-
> From: Ian Lance Taylor [mailto:i...@airs.com]
> Sent: Friday, October 13, 2017 6:45 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: gcc-patches@gcc.gnu.org; Jeff Law <l...@redhat.com>
> Subject: Re: [PATCH 09/22] Enable building libbacktrace with Intel CET
> 
> "Tsimbalist, Igor V" <igor.v.tsimbal...@intel.com> writes:
> 
> >
> > This file is included to simplify building a library that might have
> > assembler files.
> > This is an auxiliary file to automate creation of a special section in
> > an output object
> > file. Without it every assembler file has to be modified by hand to
> > include a special
> > section. This "-include cet.h " option is specified at a high level to
> > not bother if a
> > library has or does not have assembler files. The option either has no 
> > effect
> if
> > all source files are C/C++ or used only for assembler file
> > processing. The file itself
> > has an assembler code. The same code is generated by the compiler for
> each
> > input C/C++/etc. files.
> >
> > In real life a user who is going to write an assemble code and have it
> > CET compatible
> > has to add a special section to mark the object file as CET compatible.
> 
> I guess I don't understand how you can assume that general assembly code
> is CET compatible.  And if you know it is CET compatible then adding the
> section seems simple enough; people already do it routinely for
> .note.GNU-stack.
> 
> In any case a -include file such as you describe does not belong in a
> general FLAGS variable, it belongs in CPPFLAGS or, ideally, ASPPFLAGS if
> there were such a Make variable.
> 
> Ian


0009-Enable-building-libbacktrace-with-Intel-CET.PATCH
Description: 0009-Enable-building-libbacktrace-with-Intel-CET.PATCH

RE: [PATCH 07/22] Enable building libgcc with CET options.

[Tsimbalist, Igor V]

The revised patch is attached. The differences are in what options are defined 
and propagated to Makefile for CET enabling, also needed asm files are updated.

Igor


> -Original Message-
> From: Tsimbalist, Igor V
> Sent: Friday, October 13, 2017 1:02 AM
> To: Joseph Myers <jos...@codesourcery.com>
> Cc: gcc-patches@gcc.gnu.org; Jeff Law <l...@redhat.com>; i...@airs.com;
> Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Subject: RE: [PATCH 07/22] Enable building libgcc with CET options.
> 
> > -Original Message-
> > From: Joseph Myers [mailto:jos...@codesourcery.com]
> > Sent: Thursday, October 12, 2017 10:36 PM
> > To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> > Cc: gcc-patches@gcc.gnu.org; Jeff Law <l...@redhat.com>; i...@airs.com
> > Subject: Re: [PATCH 07/22] Enable building libgcc with CET options.
> >
> > On Thu, 12 Oct 2017, Tsimbalist, Igor V wrote:
> >
> > > Enable building libgcc with CET options by default on Linux/x86 if
> > > binutils supports CET v2.0.
> > > It can be disabled with --disable-cet.  It is an error to configure
> > > GCC with --enable-cet if bintuiils doesn't support CET v2.0.
> > >
> > > config/
> > >   * cet.m4: New file
> >
> > This file is checking $target.  That's only ever appropriate in directories
> > building compilers and similar tools; target library directories should 
> > check
> > $host, as the host for target libraries is the target for the compiler.
> 
> Fixed.
> 
> > This file has a comment
> >
> > > +dnl GCC_CET_LIBRARY
> > > +dnl(SHELL-CODE_HANDLER)
> >
> > which doesn't seem to match the subsequent definition of
> GCC_CET_FLAGS.
> 
> Fixed.
> 
> > I don't see any documentation of the new configure option.  I'd expect the
> > first patch adding such an option to document it in install.texi, and then
> > subsequent patches to update that documentation if those patches extend
> > the option to cover more things.
> 
> Added the description of this configure option to install.texi.
> 
> The updated patch is attached.
> 
> Igor
> 
> > --
> > Joseph S. Myers
> > jos...@codesourcery.com


0007-Enable-building-libgcc-with-CET-options.patch
Description: 0007-Enable-building-libgcc-with-CET-options.patch

RE: [PATCH] i386: Don't generate ENDBR if function is only called directly

[Tsimbalist, Igor V]

OK.

Igor


> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Tuesday, October 24, 2017 1:01 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: Uros Bizjak <ubiz...@gmail.com>; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] i386: Don't generate ENDBR if function is only called
> directly
> 
> On Mon, Oct 23, 2017 at 3:19 PM, Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com> wrote:
> > You are right. The functions in the tests should be changed to static scope
> to trigger the check in the patch. After that I expect there should be no
> endbr generated at all for the static functions and that's is wrong.
> >
> 
> Here is the updated patch with new testcases.  OK for trunk if there are
> no regressions?
> 
> Thanks.
> 
> H.J.
> >
> >> -Original Message-
> >> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> >> Sent: Tuesday, October 24, 2017 12:06 AM
> >> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> >> Cc: Uros Bizjak <ubiz...@gmail.com>; gcc-patches@gcc.gnu.org
> >> Subject: Re: [PATCH] i386: Don't generate ENDBR if function is only called
> >> directly
> >>
> >> On Mon, Oct 23, 2017 at 3:01 PM, Tsimbalist, Igor V
> >> <igor.v.tsimbal...@intel.com> wrote:
> >> > Existing tests cet-label.c cet-switch-2.c cet-sjlj-1.c cet-sjlj-3.c 
> >> > should
> catch
> >> this.
> >>
> >> There are no regressions with my patch.  Did I miss something?
> >>
> >> > Igor
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> >> >> Sent: Monday, October 23, 2017 11:50 PM
> >> >> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> >> >> Cc: Uros Bizjak <ubiz...@gmail.com>; gcc-patches@gcc.gnu.org
> >> >> Subject: Re: [PATCH] i386: Don't generate ENDBR if function is only
> called
> >> >> directly
> >> >>
> >> >> On Mon, Oct 23, 2017 at 2:44 PM, Tsimbalist, Igor V
> >> >> <igor.v.tsimbal...@intel.com> wrote:
> >> >> > The change will skip a whole function from endbr processing by
> >> >> rest_of_insert_endbranch,
> >> >> > which inserts endbr not only at the beginning of the function but
> inside
> >> the
> >> >> function's
> >> >> > body also. For example, tests with setjmp should fail.
> >> >> >
> >> >> > I would suggest to insert the check in rest_of_insert_endbranch
> >> function,
> >> >> something like this
> >> >> >
> >> >> >   if (!(lookup_attribute ("nocf_check",
> >> >> >   TYPE_ATTRIBUTES (TREE_TYPE (cfun->decl)))
> >> >> > || cgraph_node::get (fun->decl)->only_called_directly_p ())
> >> >> >
> >> >> > Igor
> >> >>
> >> >> Can you provide one test for each case to cover all of them?
> >> >>
> >> >>
> >> >> >
> >> >> >> -Original Message-
> >> >> >> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> >> >> >> Sent: Monday, October 23, 2017 9:26 PM
> >> >> >> To: H.J. Lu <hjl.to...@gmail.com>
> >> >> >> Cc: gcc-patches@gcc.gnu.org; Tsimbalist, Igor V
> >> >> >> <igor.v.tsimbal...@intel.com>
> >> >> >> Subject: Re: [PATCH] i386: Don't generate ENDBR if function is only
> >> called
> >> >> >> directly
> >> >> >>
> >> >> >> On Sun, Oct 22, 2017 at 4:13 PM, H.J. Lu <hjl.to...@gmail.com>
> wrote:
> >> >> >> > There is no need to insert ENDBR instruction if function is only
> called
> >> >> >> > directly.
> >> >> >> >
> >> >> >> > OK for trunk if there is no regressions?
> >> >> >>
> >> >> >> Patch needs to be OK'd by Igor first.
> >> >> >>
> >> >> >> Uros.
> >> >> >>
> >> >> >> > H.J.
> >> >> >> > 
> >> >> >> > gcc/
> >> >> >> >
> >> >> >> > PR target/82659
> >> >> >> > *

RE: [PATCH] i386: Don't generate ENDBR if function is only called directly

[Tsimbalist, Igor V]

You are right. The functions in the tests should be changed to static scope to 
trigger the check in the patch. After that I expect there should be no endbr 
generated at all for the static functions and that's is wrong.

Igor


> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Tuesday, October 24, 2017 12:06 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: Uros Bizjak <ubiz...@gmail.com>; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] i386: Don't generate ENDBR if function is only called
> directly
> 
> On Mon, Oct 23, 2017 at 3:01 PM, Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com> wrote:
> > Existing tests cet-label.c cet-switch-2.c cet-sjlj-1.c cet-sjlj-3.c should 
> > catch
> this.
> 
> There are no regressions with my patch.  Did I miss something?
> 
> > Igor
> >
> >
> >> -Original Message-
> >> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> >> Sent: Monday, October 23, 2017 11:50 PM
> >> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> >> Cc: Uros Bizjak <ubiz...@gmail.com>; gcc-patches@gcc.gnu.org
> >> Subject: Re: [PATCH] i386: Don't generate ENDBR if function is only called
> >> directly
> >>
> >> On Mon, Oct 23, 2017 at 2:44 PM, Tsimbalist, Igor V
> >> <igor.v.tsimbal...@intel.com> wrote:
> >> > The change will skip a whole function from endbr processing by
> >> rest_of_insert_endbranch,
> >> > which inserts endbr not only at the beginning of the function but inside
> the
> >> function's
> >> > body also. For example, tests with setjmp should fail.
> >> >
> >> > I would suggest to insert the check in rest_of_insert_endbranch
> function,
> >> something like this
> >> >
> >> >   if (!(lookup_attribute ("nocf_check",
> >> >   TYPE_ATTRIBUTES (TREE_TYPE (cfun->decl)))
> >> > || cgraph_node::get (fun->decl)->only_called_directly_p ())
> >> >
> >> > Igor
> >>
> >> Can you provide one test for each case to cover all of them?
> >>
> >>
> >> >
> >> >> -Original Message-
> >> >> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> >> >> Sent: Monday, October 23, 2017 9:26 PM
> >> >> To: H.J. Lu <hjl.to...@gmail.com>
> >> >> Cc: gcc-patches@gcc.gnu.org; Tsimbalist, Igor V
> >> >> <igor.v.tsimbal...@intel.com>
> >> >> Subject: Re: [PATCH] i386: Don't generate ENDBR if function is only
> called
> >> >> directly
> >> >>
> >> >> On Sun, Oct 22, 2017 at 4:13 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> >> >> > There is no need to insert ENDBR instruction if function is only 
> >> >> > called
> >> >> > directly.
> >> >> >
> >> >> > OK for trunk if there is no regressions?
> >> >>
> >> >> Patch needs to be OK'd by Igor first.
> >> >>
> >> >> Uros.
> >> >>
> >> >> > H.J.
> >> >> > 
> >> >> > gcc/
> >> >> >
> >> >> > PR target/82659
> >> >> > * config/i386/i386.c (pass_insert_endbranch::gate): Return
> >> >> > false if function is only called directly.
> >> >> >
> >> >> > gcc/testsuite/
> >> >> >
> >> >> > PR target/82659
> >> >> > * gcc.target/i386/pr82659-1.c: New test.
> >> >> > * gcc.target/i386/pr82659-2.c: Likewise.
> >> >> > * gcc.target/i386/pr82659-3.c: Likewise.
> >> >> > * gcc.target/i386/pr82659-4.c: Likewise.
> >> >> > * gcc.target/i386/pr82659-5.c: Likewise.
> >> >> > * gcc.target/i386/pr82659-6.c: Likewise.
> >> >> > ---
> >> >> >  gcc/config/i386/i386.c|  6 --
> >> >> >  gcc/testsuite/gcc.target/i386/pr82659-1.c | 19
> +++
> >> >> >  gcc/testsuite/gcc.target/i386/pr82659-2.c | 18
> ++
> >> >> >  gcc/testsuite/gcc.target/i386/pr82659-3.c | 21
> >> +
> >> >> >  gcc/testsuite/gcc.target/i386/pr82659-4.c | 15 +++
> >> >> >  gcc/tes

RE: [PATCH] i386: Don't generate ENDBR if function is only called directly

[Tsimbalist, Igor V]

Existing tests cet-label.c cet-switch-2.c cet-sjlj-1.c cet-sjlj-3.c should 
catch this.

Igor


> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Monday, October 23, 2017 11:50 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: Uros Bizjak <ubiz...@gmail.com>; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] i386: Don't generate ENDBR if function is only called
> directly
> 
> On Mon, Oct 23, 2017 at 2:44 PM, Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com> wrote:
> > The change will skip a whole function from endbr processing by
> rest_of_insert_endbranch,
> > which inserts endbr not only at the beginning of the function but inside the
> function's
> > body also. For example, tests with setjmp should fail.
> >
> > I would suggest to insert the check in rest_of_insert_endbranch function,
> something like this
> >
> >   if (!(lookup_attribute ("nocf_check",
> >   TYPE_ATTRIBUTES (TREE_TYPE (cfun->decl)))
> > || cgraph_node::get (fun->decl)->only_called_directly_p ())
> >
> > Igor
> 
> Can you provide one test for each case to cover all of them?
> 
> 
> >
> >> -Original Message-
> >> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> >> Sent: Monday, October 23, 2017 9:26 PM
> >> To: H.J. Lu <hjl.to...@gmail.com>
> >> Cc: gcc-patches@gcc.gnu.org; Tsimbalist, Igor V
> >> <igor.v.tsimbal...@intel.com>
> >> Subject: Re: [PATCH] i386: Don't generate ENDBR if function is only called
> >> directly
> >>
> >> On Sun, Oct 22, 2017 at 4:13 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> >> > There is no need to insert ENDBR instruction if function is only called
> >> > directly.
> >> >
> >> > OK for trunk if there is no regressions?
> >>
> >> Patch needs to be OK'd by Igor first.
> >>
> >> Uros.
> >>
> >> > H.J.
> >> > 
> >> > gcc/
> >> >
> >> > PR target/82659
> >> > * config/i386/i386.c (pass_insert_endbranch::gate): Return
> >> > false if function is only called directly.
> >> >
> >> > gcc/testsuite/
> >> >
> >> > PR target/82659
> >> > * gcc.target/i386/pr82659-1.c: New test.
> >> > * gcc.target/i386/pr82659-2.c: Likewise.
> >> > * gcc.target/i386/pr82659-3.c: Likewise.
> >> > * gcc.target/i386/pr82659-4.c: Likewise.
> >> > * gcc.target/i386/pr82659-5.c: Likewise.
> >> > * gcc.target/i386/pr82659-6.c: Likewise.
> >> > ---
> >> >  gcc/config/i386/i386.c|  6 --
> >> >  gcc/testsuite/gcc.target/i386/pr82659-1.c | 19 +++
> >> >  gcc/testsuite/gcc.target/i386/pr82659-2.c | 18 ++
> >> >  gcc/testsuite/gcc.target/i386/pr82659-3.c | 21
> +
> >> >  gcc/testsuite/gcc.target/i386/pr82659-4.c | 15 +++
> >> >  gcc/testsuite/gcc.target/i386/pr82659-5.c | 10 ++
> >> >  gcc/testsuite/gcc.target/i386/pr82659-6.c | 19 +++
> >> >  7 files changed, 106 insertions(+), 2 deletions(-)
> >> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr82659-1.c
> >> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr82659-2.c
> >> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr82659-3.c
> >> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr82659-4.c
> >> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr82659-5.c
> >> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr82659-6.c
> >> >
> >> > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> >> > index fb0b7e71469..b86504378ae 100644
> >> > --- a/gcc/config/i386/i386.c
> >> > +++ b/gcc/config/i386/i386.c
> >> > @@ -2693,9 +2693,11 @@ public:
> >> >{}
> >> >
> >> >/* opt_pass methods: */
> >> > -  virtual bool gate (function *)
> >> > +  virtual bool gate (function *fun)
> >> >  {
> >> > -  return ((flag_cf_protection & CF_BRANCH) && TARGET_IBT);
> >> > +  return ((flag_cf_protection & CF_BRANCH)
> >> > + && TARGET_IBT
> >> > + && !cgraph_node::get (fun->decl)->only_called_directly_p 
&

RE: [PATCH] i386: Don't generate ENDBR if function is only called directly

[Tsimbalist, Igor V]

The change will skip a whole function from endbr processing by 
rest_of_insert_endbranch,
which inserts endbr not only at the beginning of the function but inside the 
function's
body also. For example, tests with setjmp should fail.

I would suggest to insert the check in rest_of_insert_endbranch function, 
something like this

  if (!(lookup_attribute ("nocf_check",
  TYPE_ATTRIBUTES (TREE_TYPE (cfun->decl)))
|| cgraph_node::get (fun->decl)->only_called_directly_p ())

Igor


> -Original Message-
> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> Sent: Monday, October 23, 2017 9:26 PM
> To: H.J. Lu <hjl.to...@gmail.com>
> Cc: gcc-patches@gcc.gnu.org; Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com>
> Subject: Re: [PATCH] i386: Don't generate ENDBR if function is only called
> directly
> 
> On Sun, Oct 22, 2017 at 4:13 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> > There is no need to insert ENDBR instruction if function is only called
> > directly.
> >
> > OK for trunk if there is no regressions?
> 
> Patch needs to be OK'd by Igor first.
> 
> Uros.
> 
> > H.J.
> > 
> > gcc/
> >
> > PR target/82659
> > * config/i386/i386.c (pass_insert_endbranch::gate): Return
> > false if function is only called directly.
> >
> > gcc/testsuite/
> >
> > PR target/82659
> > * gcc.target/i386/pr82659-1.c: New test.
> > * gcc.target/i386/pr82659-2.c: Likewise.
> > * gcc.target/i386/pr82659-3.c: Likewise.
> > * gcc.target/i386/pr82659-4.c: Likewise.
> > * gcc.target/i386/pr82659-5.c: Likewise.
> > * gcc.target/i386/pr82659-6.c: Likewise.
> > ---
> >  gcc/config/i386/i386.c|  6 --
> >  gcc/testsuite/gcc.target/i386/pr82659-1.c | 19 +++
> >  gcc/testsuite/gcc.target/i386/pr82659-2.c | 18 ++
> >  gcc/testsuite/gcc.target/i386/pr82659-3.c | 21 +
> >  gcc/testsuite/gcc.target/i386/pr82659-4.c | 15 +++
> >  gcc/testsuite/gcc.target/i386/pr82659-5.c | 10 ++
> >  gcc/testsuite/gcc.target/i386/pr82659-6.c | 19 +++
> >  7 files changed, 106 insertions(+), 2 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr82659-1.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr82659-2.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr82659-3.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr82659-4.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr82659-5.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr82659-6.c
> >
> > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> > index fb0b7e71469..b86504378ae 100644
> > --- a/gcc/config/i386/i386.c
> > +++ b/gcc/config/i386/i386.c
> > @@ -2693,9 +2693,11 @@ public:
> >{}
> >
> >/* opt_pass methods: */
> > -  virtual bool gate (function *)
> > +  virtual bool gate (function *fun)
> >  {
> > -  return ((flag_cf_protection & CF_BRANCH) && TARGET_IBT);
> > +  return ((flag_cf_protection & CF_BRANCH)
> > + && TARGET_IBT
> > + && !cgraph_node::get (fun->decl)->only_called_directly_p ());
> >  }
> >
> >virtual unsigned int execute (function *)
> > diff --git a/gcc/testsuite/gcc.target/i386/pr82659-1.c
> b/gcc/testsuite/gcc.target/i386/pr82659-1.c
> > new file mode 100644
> > index 000..8f0a6906815
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/i386/pr82659-1.c
> > @@ -0,0 +1,19 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2 -fcf-protection -mcet" } */
> > +/* { dg-final { scan-assembler-times "endbr32" 1 { target ia32 } } } */
> > +/* { dg-final { scan-assembler-times "endbr64" 1 { target { ! ia32 } } } } 
> > */
> > +
> > +extern int x;
> > +
> > +static void
> > +__attribute__ ((noinline, noclone))
> > +test (int i)
> > +{
> > +  x = i;
> > +}
> > +
> > +void
> > +bar (int i)
> > +{
> > +  test (i);
> > +}
> > diff --git a/gcc/testsuite/gcc.target/i386/pr82659-2.c
> b/gcc/testsuite/gcc.target/i386/pr82659-2.c
> > new file mode 100644
> > index 000..228a20006b6
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/i386/pr82659-2.c
> > @@ -0,0 +1,18 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2 -fcf-protection -mcet" } */
> 

RE: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation

[Tsimbalist, Igor V]

I moved the tests to gcc.target/i386 directory and committed the changes.

Igor


> -Original Message-
> From: Andreas Schwab [mailto:sch...@linux-m68k.org]
> Sent: Sunday, October 22, 2017 1:41 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: Uros Bizjak <ubiz...@gmail.com>; gcc-patches@gcc.gnu.org
> Subject: Re: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation
> 
> FAIL: c-c++-common/attr-nocf-check-1a.c  -Wc++-compat   (test for
> warnings, lin\
> e 17)
> FAIL: c-c++-common/attr-nocf-check-1a.c  -Wc++-compat  (test for excess
> errors)
> Excess errors:
> xgcc: error: unrecognized command line option '-mcet'
> FAIL: c-c++-common/attr-nocf-check-3a.c  -Wc++-compat   (test for
> warnings, line 15)
> FAIL: c-c++-common/attr-nocf-check-3a.c  -Wc++-compat   (test for
> warnings, line 25)
> FAIL: c-c++-common/attr-nocf-check-3a.c  -Wc++-compat  (test for excess
> errors)
> Excess errors:
> xgcc: error: unrecognized command line option '-mcet'
> 
> Andreas.
> 
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

RE: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation

[Tsimbalist, Igor V]

Those 2 tests were removed during reviewing as they tested __builtin versions. 
ChangeLog was not updated.

Igor


> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Sunday, October 22, 2017 1:59 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: Uros Bizjak <ubiz...@gmail.com>; gcc-patches@gcc.gnu.org
> Subject: Re: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation
> 
> On Fri, Oct 13, 2017 at 3:56 AM, Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com> wrote:
> >> -Original Message-
> >> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> >> Sent: Friday, October 13, 2017 10:02 AM
> >> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> >> Cc: gcc-patches@gcc.gnu.org
> >> Subject: Re: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation
> >>
> >> On Thu, Oct 12, 2017 at 8:54 PM, Tsimbalist, Igor V
> >> <igor.v.tsimbal...@intel.com> wrote:
> >> > Attached is an updated patch according to your comments. New tests
> are
> >> > added to test ICF optimization in presence of nocf_check attribute.
> >> --- a/gcc/testsuite/c-c++-common/fcf-protection-2.c
> >> +++ b/gcc/testsuite/c-c++-common/fcf-protection-2.c
> >> @@ -1,4 +1,4 @@
> >>  /* { dg-do compile } */
> >>  /* { dg-options "-fcf-protection=branch" } */
> >> -/* { dg-error "'-fcf-protection=branch' is not supported for this target" 
> >> ""
> {
> >> target { "i?86-*-* x86_64-*-*" } } 0 } */
> >> +/* { dg-error "'-fcf-protection=branch' requires CET support on this
> >> target. Use -mcet or one of -mibt, -mshstk options to enable CET" "" {
> target {
> >> "i?86-*-* x86_64-*-*" } } 0 } */
> >>
> >> Checking for "-fcf-protection=branch' requires CET support on this target"
> >> should be enough. No need to check the whole message here and in
> other
> >> tests.
> >
> > Fixed as you suggested. Also shortened the checking string for ignoring the
> > attribute in attr-nocf-check-1.c and attr-nocf-check-3.c.
> >
> >>  /* { dg-error "'-fcf-protection=branch' is not supported for this target" 
> >> ""
> {
> >> target { ! "i?86-*-* x86_64-*-*" } } 0 } */ diff --git 
> >> a/gcc/testsuite/c-c++-
> >> common/fcf-protection-3.c
> >> b/gcc/testsuite/c-c++-common/fcf-protection-3.c
> >>
> >>
> >> --- a/gcc/testsuite/c-c++-common/fcf-protection-4.c
> >> +++ b/gcc/testsuite/c-c++-common/fcf-protection-4.c
> >> @@ -1,4 +1,4 @@
> >>  /* { dg-do compile } */
> >>  /* { dg-options "-fcf-protection=none" } */
> >> -/* { dg-bogus "'-fcf-protection=none' is not supported for this target" 
> >> "" {
> >> target { "i?86-*-* x86_64-*-*" } } 0 } */
> >> +/* { dg-bogus "'-fcf-protection=none' res CET support on this target.
> >> Use -mcet or one of -mibt, -mshstk options to enable CET" "" { target {
> "i?86-
> >> *-* x86_64-*-*" } } 0 } */
> >>  /* { dg-bogus "'-fcf-protection=none' is not supported for this target" 
> >> "" {
> >> target { ! "i?86-*-* x86_64-*-*" } } 0 } */ diff --git 
> >> a/gcc/testsuite/c-c++-
> >> common/fcf-protection-5.c
> >> b/gcc/testsuite/c-c++-common/fcf-protection-5.c
> >>
> >> The above test checks for bogus messages? -fcf-protection=none option
> >> should not generate any messages. So, the test should check that -fcf-
> >> protection=none doesn't generate any error. (And, there is a typo in the
> >> message, /s/res/requires.)
> >
> > The gcc documentation says about dg-bogus
> >
> > This DejaGnu directive appears on a source line that should not get a
> message
> > matching regexp...
> >
> > I decided to use dg-bogus to check the absence of the error. Now I
> removed both
> > lines as any additional messages should be caught as an extra messages.
> Actually
> > I will update the fcf-protection-4.c test in the generic patch.
> >
> > Updated patch is attached.
> >
> 
> ChangeLog has
> 
> * gcc.target/i386/cet-intrin-1.c: Likewise.
> * gcc.target/i386/cet-intrin-10.c: Likewise.
> * gcc.target/i386/cet-intrin-2.c: Likewise.
> * gcc.target/i386/cet-intrin-3.c: Likewise.
> * gcc.target/i386/cet-intrin-4.c: Likewise.
> * gcc.target/i386/cet-intrin-5.c: Likewise.
> * gcc.target/i386/cet-intrin-6.c: Likewise.
> * gcc.target/i386/cet-intrin-7.c: Likewise.
> * gcc.target/i386/cet-intrin-8.c: Likewise.
> * gcc.target/i386/cet-intrin-9.c: Likewise.
> 
> But there are no gcc.target/i386/cet-intrin-1.c nor
> gcc.target/i386/cet-intrin-2.c.
> 
> 
> --
> H.J.

[PATCH, committed] Add myself to MAINTAINERS

[Tsimbalist, Igor V]

ChangeLog:

2017-10-16  Igor Tsimbalist  

* MAINTAINERS (write after approval): Add myself.

Index: MAINTAINERS
===
--- MAINTAINERS (revision 253797)
+++ MAINTAINERS (working copy)
@@ -603,6 +603,7 @@
 Philipp Tomsich

 Konrad Trifunovic  
 Markus Trippelsdorf
+Igor Tsimbalist

 Martin Uecker  
 David Ung  
 Neil Vachharajani  

RE: [PATCH 09/22] Enable building libbacktrace with Intel CET

[Tsimbalist, Igor V]

> -Original Message-
> From: Ian Lance Taylor [mailto:i...@airs.com]
> Sent: Friday, October 13, 2017 1:59 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: gcc-patches@gcc.gnu.org; Jeff Law <l...@redhat.com>
> Subject: Re: [PATCH 09/22] Enable building libbacktrace with Intel CET
> 
> "Tsimbalist, Igor V" <igor.v.tsimbal...@intel.com> writes:
> 
> > Enable building libbacktrace with CET options.
> >
> > libbacktrace/
> > * configure.ac: Add CET_FLAGS to EXTRA_FLAGS.
> > * aclocal.m4: Regenerate.
> > * Makefile.in: Likewise.
> > * configure: Likewise.
> 
> > +if test x$enable_cet = xyes; then
> > +  CET_FLAGS="-fcf-protection -mcet -include cet.h"
> > +fi
> 
> Is this really right?  Why the -include option?  CET protection sounds like it
> should work for any language, but -include is C-specific and doesn't seem to
> have anything to do with code generation.

This file is included to simplify building a library that might have assembler 
files.
This is an auxiliary file to automate creation of a special section in an 
output object
file. Without it every assembler file has to be modified by hand to include a 
special
section. This "-include cet.h " option is specified at a high level to not 
bother if a
library has or does not have assembler files. The option either has no effect if
all source files are C/C++ or used only for assembler file processing. The file 
itself
has an assembler code. The same code is generated by the compiler for each
input C/C++/etc. files.

In real life a user who is going to write an assemble code and have it CET 
compatible
has to add a special section to mark the object file as CET compatible.

Igor

> Of course, for libbacktrace, that is a generated file.  The patch to
> libbacktrace/configure.ac is fine if the general approach is approved.
> 
> Ian

RE: [PATCH 13/22] Enable building libstdc++-v3 with Intel CET

[Tsimbalist, Igor V]

Added libstd...@gcc.gnu.org


> -Original Message-
> From: Tsimbalist, Igor V
> Sent: Thursday, October 12, 2017 10:24 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Jeff Law <l...@redhat.com>; jwak...@redhat.com; Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com>
> Subject: [PATCH 13/22] Enable building libstdc++-v3 with Intel CET
> 
> Enable building libstdc++v3 with CET options.
> 
> libstdc++-v3/
>   * acinclude.m4: Add cet.m4.
>   * configure.ac: Set CET_FLAGS. Update EXTRA_CFLAGS.
>   * libsupc++/Makefile.am: Add EXTRA_CFLAGS.
>   * Makefile.in: Regenerate.
>   * configure: Likewise.
>   * doc/Makefile.in: Likewise.
>   * include/Makefile.in: Likewise.
>   * libsupc++/Makefile.in: Likewise.
>   * po/Makefile.in: Likewise.
>   * python/Makefile.in: Likewise.
>   * src/Makefile.in: Likewise.
>   * src/c++11/Makefile.in: Likewise.
>   * src/c++98/Makefile.in: Likewise.
>   * src/filesystem/Makefile.in: Likewise.
>   * testsuite/Makefile.in: Likewise.

RE: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation

[Tsimbalist, Igor V]

> -Original Message-
> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> Sent: Friday, October 13, 2017 10:02 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation
> 
> On Thu, Oct 12, 2017 at 8:54 PM, Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com> wrote:
> > Attached is an updated patch according to your comments. New tests are
> > added to test ICF optimization in presence of nocf_check attribute.
> --- a/gcc/testsuite/c-c++-common/fcf-protection-2.c
> +++ b/gcc/testsuite/c-c++-common/fcf-protection-2.c
> @@ -1,4 +1,4 @@
>  /* { dg-do compile } */
>  /* { dg-options "-fcf-protection=branch" } */
> -/* { dg-error "'-fcf-protection=branch' is not supported for this target" "" 
> {
> target { "i?86-*-* x86_64-*-*" } } 0 } */
> +/* { dg-error "'-fcf-protection=branch' requires CET support on this
> target. Use -mcet or one of -mibt, -mshstk options to enable CET" "" { target 
> {
> "i?86-*-* x86_64-*-*" } } 0 } */
> 
> Checking for "-fcf-protection=branch' requires CET support on this target"
> should be enough. No need to check the whole message here and in other
> tests.

Fixed as you suggested. Also shortened the checking string for ignoring the
attribute in attr-nocf-check-1.c and attr-nocf-check-3.c.

>  /* { dg-error "'-fcf-protection=branch' is not supported for this target" "" 
> {
> target { ! "i?86-*-* x86_64-*-*" } } 0 } */ diff --git a/gcc/testsuite/c-c++-
> common/fcf-protection-3.c
> b/gcc/testsuite/c-c++-common/fcf-protection-3.c
> 
> 
> --- a/gcc/testsuite/c-c++-common/fcf-protection-4.c
> +++ b/gcc/testsuite/c-c++-common/fcf-protection-4.c
> @@ -1,4 +1,4 @@
>  /* { dg-do compile } */
>  /* { dg-options "-fcf-protection=none" } */
> -/* { dg-bogus "'-fcf-protection=none' is not supported for this target" "" {
> target { "i?86-*-* x86_64-*-*" } } 0 } */
> +/* { dg-bogus "'-fcf-protection=none' res CET support on this target.
> Use -mcet or one of -mibt, -mshstk options to enable CET" "" { target { "i?86-
> *-* x86_64-*-*" } } 0 } */
>  /* { dg-bogus "'-fcf-protection=none' is not supported for this target" "" {
> target { ! "i?86-*-* x86_64-*-*" } } 0 } */ diff --git a/gcc/testsuite/c-c++-
> common/fcf-protection-5.c
> b/gcc/testsuite/c-c++-common/fcf-protection-5.c
> 
> The above test checks for bogus messages? -fcf-protection=none option
> should not generate any messages. So, the test should check that -fcf-
> protection=none doesn't generate any error. (And, there is a typo in the
> message, /s/res/requires.)

The gcc documentation says about dg-bogus

This DejaGnu directive appears on a source line that should not get a message
matching regexp...

I decided to use dg-bogus to check the absence of the error. Now I removed both
lines as any additional messages should be caught as an extra messages. Actually
I will update the fcf-protection-4.c test in the generic patch.

Updated patch is attached. 

Igor

> Uros.
> 
> > Igor
> >
> >
> >> -Original Message-
> >> From: Tsimbalist, Igor V
> >> Sent: Tuesday, September 19, 2017 11:30 PM
> >> To: Uros Bizjak <ubiz...@gmail.com>
> >> Cc: gcc-patches@gcc.gnu.org; Tsimbalist, Igor V
> >> <igor.v.tsimbal...@intel.com>
> >> Subject: RE: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation
> >>
> >> > -Original Message-
> >> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> >> > ow...@gcc.gnu.org] On Behalf Of Uros Bizjak
> >> > Sent: Tuesday, September 19, 2017 6:13 PM
> >> > To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> >> > Cc: gcc-patches@gcc.gnu.org
> >> > Subject: Re:
> >> > 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation
> >> >
> >> > On Tue, Sep 19, 2017 at 5:18 PM, Tsimbalist, Igor V
> >> > <igor.v.tsimbal...@intel.com> wrote:
> >> > >> -Original Message-
> >> > >> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> >> > >> ow...@gcc.gnu.org] On Behalf Of Uros Bizjak
> >> > >> Sent: Monday, September 18, 2017 12:17 PM
> >> > >> To: gcc-patches@gcc.gnu.org
> >> > >> Cc: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>;
> >> > >> Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> >> > >> Su

RE: [PATCH 07/22] Enable building libgcc with CET options.

[Tsimbalist, Igor V]

> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Thursday, October 12, 2017 10:36 PM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Cc: gcc-patches@gcc.gnu.org; Jeff Law <l...@redhat.com>; i...@airs.com
> Subject: Re: [PATCH 07/22] Enable building libgcc with CET options.
> 
> On Thu, 12 Oct 2017, Tsimbalist, Igor V wrote:
> 
> > Enable building libgcc with CET options by default on Linux/x86 if
> > binutils supports CET v2.0.
> > It can be disabled with --disable-cet.  It is an error to configure
> > GCC with --enable-cet if bintuiils doesn't support CET v2.0.
> >
> > config/
> > * cet.m4: New file
> 
> This file is checking $target.  That's only ever appropriate in directories
> building compilers and similar tools; target library directories should check
> $host, as the host for target libraries is the target for the compiler.

Fixed.

> This file has a comment
> 
> > +dnl GCC_CET_LIBRARY
> > +dnl(SHELL-CODE_HANDLER)
> 
> which doesn't seem to match the subsequent definition of GCC_CET_FLAGS.

Fixed.

> I don't see any documentation of the new configure option.  I'd expect the
> first patch adding such an option to document it in install.texi, and then
> subsequent patches to update that documentation if those patches extend
> the option to cover more things.

Added the description of this configure option to install.texi. 

The updated patch is attached.

Igor

> --
> Joseph S. Myers
> jos...@codesourcery.com


0007-Enable-building-libgcc-with-CET-options.patch
Description: 0007-Enable-building-libgcc-with-CET-options.patch

[PATCH 21/22] Enable building libitm with Intel CET

[Tsimbalist, Igor V]

Enable building libitm with Intel CET options.

libitm/
* Makefile.in: Regenerate.
* acinclude.m4: Add enable.m4 and cet.m4.
* config/x86/sjlj.S
(_ITM_beginTransaction): Save Shadow Stack pointer.
(GTM_longjmp): Restore Shadow Stack pointer.
* config/x86/target.h (struct gtm_jmpbuf):
Add Shadow Stack pointer.
* configure: Regenerate.
* configure.ac: Set CET_FLAGS. Update XCFLAGS, libtool_VERSION.
* testsuite/Makefile.in: Regenerate.

* config/cet.m4: Define ENABLE_CET_COMPATIBILITY. Set
enable_cet_compatibility.


0021-Enable-building-libitm-with-Intel-CET.PATCH
Description: 0021-Enable-building-libitm-with-Intel-CET.PATCH

[PATCH 20/22] Enable building libobjc with Intel CET

[Tsimbalist, Igor V]

Enable building libobjc with Intel CET options.

libobjc/
* Makefile.in: Regenerate.
* aclocal.m4: Likeiwse.
* configure: Likewise.
* configure.ac: Set CET_FLAGS. Update XCFLAGS.



0020-Enable-building-libobjc-with-Intel-CET.PATCH
Description: 0020-Enable-building-libobjc-with-Intel-CET.PATCH

[PATCH 19/22] Enable building libgfortran with Intel CET

[Tsimbalist, Igor V]

Enable building libgfortran with Intel CET options.

libgfortran/
* acinclude.m4: Add enable.m4, cet.m4.
* configure: Regenerate.
* configure.ac: Set CET_FLAGS. Update AM_FCFLAGS, AM_CFLAGS,
CFLAGS.


0019-Enable-building-libgfortran-with-Intel-CET.PATCH
Description: 0019-Enable-building-libgfortran-with-Intel-CET.PATCH

[PATCH 18/22] Enable building libmpx with Intel CET

[Tsimbalist, Igor V]

Enable building libmpx with Intel CET options.

libmpx/
* Makefile.in: Regenerate.
* acinclude.m4: Add enable.m4 and cet.m4.
* configure: Regenerate.
* configure.ac: Set CET_FLAGS. Update XCFLAGS.
* mpxrt/Makefile.am: Update libmpx_la_CFLAGS.
* mpxrt/Makefile.in: Regenerate.
* mpxwrap/Makefile.am: Add AM_CFLAGS. Update
* libmpxwrappers_la_CFLAGS.
* mpxwrap/Makefile.in: Regenerate.



0018-Enable-building-libmpx-with-Intel-CET.PATCH
Description: 0018-Enable-building-libmpx-with-Intel-CET.PATCH

[PATCH 17/22] Enable building libquadmath with Intel CET

[Tsimbalist, Igor V]

Enable building libquadmath with Intel CET options.

libquadmath/
* Makefile.am: Update AM_CFLAGS.
* Makefile.in: Regenerate:
* acinclude.m4: Add enable.m4 and cet.m4.
* configure: Regenerate.
* configure.ac: Set CET_FLAGS. Update XCFLAGS.



0017-Enable-building-libquadmath-with-Intel-CET.PATCH
Description: 0017-Enable-building-libquadmath-with-Intel-CET.PATCH

[PATCH 16/22] Enable building libssp with Intel CET

[Tsimbalist, Igor V]

Enable building libssp with Intel CET options.

libssp/
* Makefile.am: Update AM_CFLAGS.
* Makefile.in: Regenerate.
* configure: Likewise.
* aclocal.m4: Likewise.
* configure.ac: Set CET_FLAGS. Update XCFLAGS.



0016-Enable-building-libssp-with-Intel-CET.PATCH
Description: 0016-Enable-building-libssp-with-Intel-CET.PATCH

[PATCH 15/22] Enable building libvtv with Intel CET

[Tsimbalist, Igor V]

Enable building libvtv with Intel CET options.

libvtv/
* acinclude.m4: Add enable.m4 and cet.m4.
* libvtv/configure: Regenerate.
* libvtv/configure.ac: Set CET_FLAGS. Update XCFLAGS.



0015-Enable-building-libvtv-with-Intel-CET.PATCH
Description: 0015-Enable-building-libvtv-with-Intel-CET.PATCH

[PATCH 14/22] Enable building libsanitizer with Intel CET

[Tsimbalist, Igor V]

Enable building libsanitizer with Intel CET options.

libsanitizer/
* acinclude.m4: Add enable.m4 and cet.m4.
* Makefile.in: Regenerate.
* asan/Makefile.am: Update AM_CXXFLAGS.
* asan/Makefile.in: Regenerate.
* configure: Likewise.
* configure.ac: Set CET_FLAGS. Update EXTRA_CFLAGS,
* EXTRA_CXXFLAGS.
* interception/Makefile.am: Update AM_CXXFLAGS.
* interception/Makefile.in: Regenerate.
* libbacktrace/Makefile.am: Update AM_CFLAGS, AM_CXXFLAGS.
* libbacktrace/Makefile.in: Regenerate.
* lsan/Makefile.am: Update AM_CXXFLAGS.
* lsan/Makefile.in: Regenerate.
* sanitizer_common/Makefile.am: Update AM_CXXFLAGS.
* sanitizer_common/Makefile.in: Regenerate.
* tsan/Makefile.am: Update AM_CXXFLAGS.
* tsan/Makefile.in: Regenerate.
* ubsan/Makefile.am: Update AM_CXXFLAGS.
* ubsan/Makefile.in: Regenerate.


0014-Enable-building-libsanitizer-with-Intel-CET.PATCH
Description: 0014-Enable-building-libsanitizer-with-Intel-CET.PATCH

[PATCH 13/22] Enable building libstdc++-v3 with Intel CET

[Tsimbalist, Igor V]

Enable building libstdc++v3 with CET options.

libstdc++-v3/
* acinclude.m4: Add cet.m4.
* configure.ac: Set CET_FLAGS. Update EXTRA_CFLAGS.
* libsupc++/Makefile.am: Add EXTRA_CFLAGS.
* Makefile.in: Regenerate.
* configure: Likewise.
* doc/Makefile.in: Likewise.
* include/Makefile.in: Likewise.
* libsupc++/Makefile.in: Likewise.
* po/Makefile.in: Likewise.
* python/Makefile.in: Likewise.
* src/Makefile.in: Likewise.
* src/c++11/Makefile.in: Likewise.
* src/c++98/Makefile.in: Likewise.
* src/filesystem/Makefile.in: Likewise.
* testsuite/Makefile.in: Likewise.



0013-Enable-building-libstdc-v3-with-Intel-CET.PATCH
Description: 0013-Enable-building-libstdc-v3-with-Intel-CET.PATCH

[PATCH 12/22] Enable building libgomp with Intel CET

[Tsimbalist, Igor V]

Enable building libgomp with CET options.

libgomp/
* configure.ac: Set CET_FLAGS, update XCFLAGS and FCFLAGS.
* acinclude.m4: Add cet.m4.
* configure: Regenerate.
* Makefile.in: Likewise.
* testsuite/Makefile.in: Likewise



0012-Enable-building-libgomp-with-Intel-CET.PATCH
Description: 0012-Enable-building-libgomp-with-Intel-CET.PATCH

[PATCH 11/22] Enable building libatomic with Intel CET

[Tsimbalist, Igor V]

Enable building libatomic with CET options.

libatomic/
* configure.ac: Set CET_FLAGS, update XCFLAGS.
* acinclude.m4: Add cet.m4 and enable.m4.
* configure: Regenerate.
* Makefile.in: Likewise.
* testsuite/Makefile.in: Likewise.



0011-Enable-building-libatomic-with-Intel-CET.PATCH
Description: 0011-Enable-building-libatomic-with-Intel-CET.PATCH

[PATCH 10/22] Enable building libcilkrts with Intel CET

[Tsimbalist, Igor V]

Enable building libcilkrts with CET options.

libcilkrts/
* Makefile.am: Add AM_CXXFLAGS and XCXXFLAGS.
* configure.ac: Set CET_FLAGS, update XCFLAGS, XCXXFLAGS.
* Makefile.in: Regenerate.
* aclocal.m4: Likewise.
* configure: Likewise.



0010-Enable-building-libcilkrts-with-Intel-CET.PATCH
Description: 0010-Enable-building-libcilkrts-with-Intel-CET.PATCH

[PATCH 09/22] Enable building libbacktrace with Intel CET

[Tsimbalist, Igor V]

Enable building libbacktrace with CET options.

libbacktrace/
* configure.ac: Add CET_FLAGS to EXTRA_FLAGS.
* aclocal.m4: Regenerate.
* Makefile.in: Likewise.
* configure: Likewise.

Igor




0009-Enable-building-libbacktrace-with-Intel-CET.PATCH
Description: 0009-Enable-building-libbacktrace-with-Intel-CET.PATCH

[PATCH 08/22] Add Intel CET support for EH in libgcc.

[Tsimbalist, Igor V]

Control-flow Enforcement Technology (CET), published by Intel, Introduces
the Shadow Stack feature, which ensures a return from a function is done
to exactly the same location from where the function was called. When EH
is present the control-flow transfer may skip some stack frames and the
shadow stack has to be adjusted not to signal a violation of a
control-flow transfer. It's done by counting a number of skipping frames
and adjusting shadow stack pointer by this number.

gcc/
* config/i386/i386.c (ix86_expand_epilogue): Change simple
return to indirect jump for EH return. Change explicit 'false'
argument in pro_epilogue_adjust_stack with a value of
flag_cf_protection.
* config/i386/i386.md (simple_return_indirect_internal): Remove
SImode restriction to support 64-bit.

libgcc/
* config/i386/linux-unwind.h: Include
config/i386/shadow-stack-unwind.h.
* config/i386/shadow-stack-unwind.h: New file.
* unwind-dw2.c: (uw_install_context): Add a FRAMES argument and
pass it to _Unwind_Frames_Extra.
* unwind-generic.h (FRAMES_P_DECL): New.
(FRAMES_VAR): Likewise.
(FRAMES_VAR_P): Likewise.
(FRAMES_VAR_DECL): Likewise.
(FRAMES_VAR_DECL_1): Likewise.
(FRAMES_VAR_INC): Likewise.
(FRAMES_P_UPDATE): Likewise.
(_Unwind_Frames_Extra): Likewise.
* unwind.inc (_Unwind_RaiseException_Phase2): Use FRAMES_P_DECL,
FRAMES_VAR_DECL_1, FRAMES_VAR_INC and FRAMES_P_UPDATE.
(_Unwind_RaiseException): Use FRAMES_VAR_DECL, FRAMES_VAR_P and
FRAMES_VAR.
(_Unwind_ForcedUnwind_Phase2): Use FRAMES_P_DECL,
FRAMES_VAR_DECL_1, FRAMES_VAR_INC, FRAMES_P_UPDATE.
(_Unwind_ForcedUnwind): Use FRAMES_VAR_DECL, FRAMES_VAR_P and
FRAMES_VAR.
(_Unwind_Resume): Use FRAMES_VAR_DECL, FRAMES_VAR_P and
FRAMES_VAR.
(_Unwind_Resume_or_Rethrow): Use FRAMES_VAR_DECL, FRAMES_VAR_P
and FRAMES_VAR. 

Igor




0008-Add-Intel-CET-support-for-EH-in-libgcc.patch
Description: 0008-Add-Intel-CET-support-for-EH-in-libgcc.patch

[PATCH 07/22] Enable building libgcc with CET options.

[Tsimbalist, Igor V]

Enable building libgcc with CET options by default on Linux/x86 if
binutils supports CET v2.0.
It can be disabled with --disable-cet.  It is an error to configure
GCC with --enable-cet if bintuiils doesn't support CET v2.0.

config/
* cet.m4: New file

gcc/
* config.gcc (extra_headers): Add cet.h for Linux/x86 targets.
* config/i386/cet.h: New file.

libgcc/
* Makefile.in (configure_deps): Add $(srcdir)/../config/cet.m4.
(CET_FLAGS): New.
* config/i386/t-linux
(HOST_LIBGCC2_CFLAGS): Add $(CET_FLAGS).
(CRTSTUFF_T_CFLAGS): Add $(CET_FLAGS).
* configure.ac: Include ../config/cet.m4.
Set and substitute CET_FLAGS.
* configure: Regenerated.

Igor




0007-Enable-building-libgcc-with-CET-options.patch
Description: 0007-Enable-building-libgcc-with-CET-options.patch

RE: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation

[Tsimbalist, Igor V]

Attached is an updated patch according to your comments. New tests are
added to test ICF optimization in presence of nocf_check attribute.

Igor


> -Original Message-
> From: Tsimbalist, Igor V
> Sent: Tuesday, September 19, 2017 11:30 PM
> To: Uros Bizjak <ubiz...@gmail.com>
> Cc: gcc-patches@gcc.gnu.org; Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com>
> Subject: RE: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation
> 
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Uros Bizjak
> > Sent: Tuesday, September 19, 2017 6:13 PM
> > To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation
> >
> > On Tue, Sep 19, 2017 at 5:18 PM, Tsimbalist, Igor V
> > <igor.v.tsimbal...@intel.com> wrote:
> > >> -Original Message-
> > >> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > >> ow...@gcc.gnu.org] On Behalf Of Uros Bizjak
> > >> Sent: Monday, September 18, 2017 12:17 PM
> > >> To: gcc-patches@gcc.gnu.org
> > >> Cc: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; Tsimbalist,
> > >> Igor V <igor.v.tsimbal...@intel.com>
> > >> Subject: Re:
> > >> 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation
> > >>
> > >> Hello!
> > >>
> > >> > gcc/testsuite/
> > >> >
> > >> > * g++.dg/cet-notrack-1.C: New test.
> > >> > * gcc.target/i386/cet-intrin-1.c: Likewise.
> > >> > * gcc.target/i386/cet-intrin-10.c: Likewise.
> > >> > * gcc.target/i386/cet-intrin-2.c: Likewise.
> > >> > * gcc.target/i386/cet-intrin-3.c: Likewise.
> > >> > * gcc.target/i386/cet-intrin-4.c: Likewise.
> > >> > * gcc.target/i386/cet-intrin-5.c: Likewise.
> > >> > * gcc.target/i386/cet-intrin-6.c: Likewise.
> > >> > * gcc.target/i386/cet-intrin-7.c: Likewise.
> > >> > * gcc.target/i386/cet-intrin-8.c: Likewise.
> > >> > * gcc.target/i386/cet-intrin-9.c: Likewise.
> > >> > * gcc.target/i386/cet-label.c: Likewise.
> > >> > * gcc.target/i386/cet-notrack-1a.c: Likewise.
> > >> > * gcc.target/i386/cet-notrack-1b.c: Likewise.
> > >> > * gcc.target/i386/cet-notrack-2a.c: Likewise.
> > >> > * gcc.target/i386/cet-notrack-2b.c: Likewise.
> > >> > * gcc.target/i386/cet-notrack-3.c: Likewise.
> > >> > * gcc.target/i386/cet-notrack-4a.c: Likewise.
> > >> > * gcc.target/i386/cet-notrack-4b.c: Likewise.
> > >> > * gcc.target/i386/cet-notrack-5a.c: Likewise.
> > >> > * gcc.target/i386/cet-notrack-5b.c: Likewise.
> > >> > * gcc.target/i386/cet-notrack-6a.c: Likewise.
> > >> > * gcc.target/i386/cet-notrack-6b.c: Likewise.
> > >> > * gcc.target/i386/cet-notrack-7.c: Likewise.
> > >> > * gcc.target/i386/cet-property-1.c: Likewise.
> > >> > * gcc.target/i386/cet-property-2.c: Likewise.
> > >> > * gcc.target/i386/cet-rdssp-1.c: Likewise.
> > >> > * gcc.target/i386/cet-sjlj-1.c: Likewise.
> > >> > * gcc.target/i386/cet-sjlj-2.c: Likewise.
> > >> > * gcc.target/i386/cet-sjlj-3.c: Likewise.
> > >> > * gcc.target/i386/cet-switch-1.c: Likewise.
> > >> > * gcc.target/i386/cet-switch-2.c: Likewise.
> > >> > * lib/target-supports.exp (check_effective_target_cet): New proc.
> > >>
> > >> A couple of questions:
> > >>
> > >> +/* { dg-do compile } */
> > >> +/* { dg-options "-O2 -mcet" } */
> > >> +/* { dg-final { scan-assembler-times "setssbsy" 2 } } */
> > >> +
> > >> +#include 
> > >> +
> > >> +void f1 (void)
> > >> +{
> > >> +  __builtin_ia32_setssbsy ();
> > >> +}
> > >> +
> > >> +void f2 (void)
> > >> +{
> > >> +  _setssbsy ();
> > >> +}
> > >>
> > >> Is there a reason that both, __builtin and intrinsic versions are
> > >> tested in a couple of places? The intrinsic version is just a
> > >> wrapper for __builtin, so IMO testing intrinsic version should be
> enough.
> > > No strong reason. Just to check that intrinsic names are recognized
> > > and
> > processed correctly.
> > >

RE: 0004-Part-4.-Update-x86-backend-to-enable-Intel-CET

[Tsimbalist, Igor V]

Uros,

Attached is an updated patch. The main difference is in option name and 
attribute name change. Other code is the same.

Igor


> -Original Message-
> From: Tsimbalist, Igor V
> Sent: Tuesday, September 19, 2017 5:06 PM
> To: Uros Bizjak <ubiz...@gmail.com>; gcc-patches@gcc.gnu.org
> Cc: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>
> Subject: RE: 0004-Part-4.-Update-x86-backend-to-enable-Intel-CET
> 
> Uros, thank you for the approval. Based on the approval of the first 3 patches
> (I've submitted them today), I need to adjust option and attribute names. I
> will resubmit the patch when I fix option and attribute names.
> 
> Thanks,
> Igor
> 
> 
> > -Original Message-
> > From: Uros Bizjak [mailto:ubiz...@gmail.com]
> > Sent: Monday, September 18, 2017 11:58 AM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; Tsimbalist, Igor
> > V <igor.v.tsimbal...@intel.com>
> > Subject: Re: 0004-Part-4.-Update-x86-backend-to-enable-Intel-CET
> >
> > Hello!
> >
> > > gcc/
> > >
> > > * common/config/i386/i386-common.c (OPTION_MASK_ISA_IBT_SET):
> > New.
> > > (OPTION_MASK_ISA_SHSTK_SET): Likewise.
> > > (OPTION_MASK_ISA_IBT_UNSET): Likewise.
> > > (OPTION_MASK_ISA_SHSTK_UNSET): Likewise.
> > > (ix86_handle_option): Add -mibt, -mshstk, -mcet handling.
> > > * config.gcc (extra_headers): Add cetintrin.h for x86 targets.
> > > (extra_objs): Add cet.o for Linux/x86 targets.
> > > (tmake_file): Add i386/t-cet for Linux/x86 targets.
> > > * config/i386/cet.c: New file.
> > > * config/i386/cetintrin.h: Likewise.
> > > * config/i386/t-cet: Likewise.
> > > * config/i386/cpuid.h (bit_SHSTK): New.
> > > (bit_IBT): Likewise.
> > > * config/i386/driver-i386.c (host_detect_local_cpu): Detect and pass
> > > IBT and SHSTK bits.
> > > * config/i386/i386-builtin-types.def
> > > (VOID_FTYPE_UNSIGNED_PVOID): New.
> > > (VOID_FTYPE_UINT64_PVOID): Likewise.
> > > * config/i386/i386-builtin.def: Add CET intrinsics.
> > > * config/i386/i386-c.c (ix86_target_macros_internal): Add
> > > OPTION_MASK_ISA_IBT, OPTION_MASK_ISA_SHSTK handling.
> > > * config/i386/i386-passes.def: Add pass_insert_endbranch pass.
> > > * config/i386/i386-protos.h (make_pass_insert_endbranch): New
> > > prototype.
> > > * config/i386/i386.c (rest_of_insert_endbranch): New.
> > > (pass_data_insert_endbranch): Likewise.
> > > (pass_insert_endbranch): Likewise.
> > > (make_pass_insert_endbranch): Likewise.
> > > (ix86_notrack_prefixed_insn_p): Likewise.
> > > (ix86_target_string): Add -mibt, -mshstk flags.
> > > (ix86_option_override_internal): Add flag_instrument_control_flow
> > > processing.
> > > (ix86_valid_target_attribute_inner_p): Set OPT_mibt, OPT_mshstk.
> > > (ix86_print_operand): Add 'notrack' prefix output.
> > > (ix86_init_mmx_sse_builtins): Add CET intrinsics.
> > > (ix86_expand_builtin): Expand CET intrinsics.
> > > (x86_output_mi_thunk): Add 'endbranch' instruction.
> > > * config/i386/i386.h (TARGET_IBT): New.
> > > (TARGET_IBT_P): Likewise.
> > > (TARGET_SHSTK): Likewise.
> > > (TARGET_SHSTK_P): Likewise.
> > > * config/i386/i386.md (unspecv): Add UNSPECV_NOP_RDSSP,
> > > UNSPECV_INCSSP, UNSPECV_SAVEPREVSSP, UNSPECV_RSTORSSP,
> > UNSPECV_WRSS,
> > > UNSPECV_WRUSS, UNSPECV_SETSSBSY, UNSPECV_CLRSSBSY.
> > > (builtin_setjmp_setup): New pattern.
> > > (builtin_longjmp): Likewise.
> > > (rdssp): Likewise.
> > > (incssp): Likewise.
> > > (saveprevssp): Likewise.
> > > (rstorssp): Likewise.
> > > (wrss): Likewise.
> > > (wruss): Likewise.
> > > (setssbsy): Likewise.
> > > (clrssbsy): Likewise.
> > > (nop_endbr): Likewise.
> > > * config/i386/i386.opt: Add -mcet, -mibt, -mshstk and -mcet-switch
> > > options.
> > > * config/i386/immintrin.h: Include .
> > > * config/i386/linux-common.h
> > > (file_end_indicate_exec_stack_and_cet): New prototype.
> > > (TARGET_ASM_FILE_END): New.
> >
> > LGTM.
> >
> > OK for mainline.
> >
> > Thanks,
> > Uros.


0004-Update-x86-backend-to-enable-Intel-CET.PATCH
Description: 0004-Update-x86-backend-to-enable-Intel-CET.PATCH

RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling

[Tsimbalist, Igor V]

> Seems reasonable.  As a result something like
> check_missing_nocf_check_attribute is going to just go away along with the
> code in *-typeck.c which called it, right?  If so that seems like a nice 
> cleanup.
Yes, you are right.

Updated patch is attached.

Igor

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Thursday, October 12, 2017 8:07 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Cc: richard.guent...@gmail.com
> Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> 
> On 10/05/2017 04:20 AM, Tsimbalist, Igor V wrote:
> > I would like to implement the patch in a bit different way depending
> > on answers I will get for my following proposals:
> >
> > - I propose to make a type with 'nocf_check' attribute to be different from
> type w/o the attribute.
> >The reason is that the type with 'nocf_check' attribute implies different
> code generation. It will be
> >done by setting affects_type_identity field to true for the attribute. 
> > That
> in turn will trigger
> >needed or expected type checking;
> Seems reasonable.  As a result something like
> check_missing_nocf_check_attribute is going to just go away along with the
> code in *-typeck.c which called it, right?  If so that seems like a nice 
> cleanup.
> 
> 
> >
> > - I propose to ignore the 'nocf_check' attribute if 'fcf-protection' option 
> > is
> not specified and output
> >the warning about this. If there is no instrumentation the type with
> attribute should not be treated
> >differently from type w/o the attribute (see previous item) and should
> not be recorded into the
> >type.
> Seems reasonable.
> >
> > If it's ok, please ignore my previous patch (version#3) and I will post the
> updated patch shortly.
> OK.  FWIW, I think we're ready to ACK on this.  So get it posted :-)
> 
> jeff


0001-Add-generic-part-for-Intel-CET-enabling-fcf-protecti.patch
Description: 0001-Add-generic-part-for-Intel-CET-enabling-fcf-protecti.patch

RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling

[Tsimbalist, Igor V]

I would like to implement the patch in a bit different way depending on answers 
I will get for
my following proposals:

- I propose to make a type with 'nocf_check' attribute to be different from 
type w/o the attribute.
   The reason is that the type with 'nocf_check' attribute implies different 
code generation. It will be
   done by setting affects_type_identity field to true for the attribute. That 
in turn will trigger
   needed or expected type checking;

- I propose to ignore the 'nocf_check' attribute if 'fcf-protection' option is 
not specified and output
   the warning about this. If there is no instrumentation the type with 
attribute should not be treated
   differently from type w/o the attribute (see previous item) and should not 
be recorded into the
   type.

If it's ok, please ignore my previous patch (version#3) and I will post the 
updated patch shortly.

Igor


> -Original Message-
> From: Tsimbalist, Igor V
> Sent: Friday, September 29, 2017 6:04 PM
> To: Jeff Law <l...@redhat.com>; gcc-patches@gcc.gnu.org
> Cc: richard.guent...@gmail.com; Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com>
> Subject: RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> 
> Updated patch, version #3.
> 
> Igor
> 
> 
> > -Original Message-
> > From: Tsimbalist, Igor V
> > Sent: Friday, September 29, 2017 4:32 PM
> > To: Jeff Law <l...@redhat.com>; gcc-patches@gcc.gnu.org
> > Cc: richard.guent...@gmail.com; Tsimbalist, Igor V
> > <igor.v.tsimbal...@intel.com>
> > Subject: RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> >
> > > -Original Message-----
> > > From: Jeff Law [mailto:l...@redhat.com]
> > > Sent: Friday, September 29, 2017 12:44 AM
> > > To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> > > patc...@gcc.gnu.org
> > > Cc: richard.guent...@gmail.com
> > > Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> > >
> > > On 09/19/2017 07:39 AM, Tsimbalist, Igor V wrote:
> > > > Here is an updated patch (version #2). The main differences are:
> > > >
> > > > - Change attribute and option names;
> > > > - Add additional parameter to gimple_build_call_from_tree by
> > > > adding a
> > > type parameter and
> > > >   use it 'nocf_check' attribute propagation;
> > > > - Reimplement fixes in expand_call_stmt to propagate 'nocf_check'
> > > > attribute;
> > > > - Consider 'nocf_check' attribute in Identical Code Folding (ICF)
> > > > optimization;
> > > > - Add warning for type inconsistency regarding 'nocf_check'
> > > > attribute;
> > > > - Many small fixes;
> > > >
> > > > gcc/c-family/
> > > > * c-attribs.c (handle_nocf_check_attribute): New function.
> > > > (c_common_attribute_table): Add 'nocf_check' handling.
> > > > * c-common.c (check_missing_format_attribute): New function.
> > > > * c-common.h: Likewise.
> > > >
> > > > gcc/c/
> > > > * c-typeck.c (convert_for_assignment): Add check for nocf_check
> > > > attribute.
> > > > * gimple-parser.c: Add second argument NULL to
> > > > gimple_build_call_from_tree.
> > > >
> > > > gcc/cp/
> > > > * typeck.c (convert_for_assignment): Add check for nocf_check
> > > > attribute.
> > > >
> > > > gcc/
> > > > * cfgexpand.c (expand_call_stmt): Set REG_CALL_NOCF_CHECK for
> > > > call insn.
> > > > * combine.c (distribute_notes): Add REG_CALL_NOCF_CHECK
> > > handling.
> > > > * common.opt: Add fcf-protection flag.
> > > > * emit-rtl.c (try_split): Add REG_CALL_NOCF_CHECK handling.
> > > > * flag-types.h: Add enum cf_protection_level.
> > > > * gimple.c (gimple_build_call_from_tree): Add second parameter.
> > > > Add 'nocf_check' attribute propagation to gimple call.
> > > > * gimple.h (gf_mask): Add GF_CALL_NOCF_CHECK.
> > > > (gimple_call_nocf_check_p): New function.
> > > > (gimple_call_set_nocf_check): Likewise.
> > > > * gimplify.c: Add second argument to 
> > > > gimple_build_call_from_tree.
> > > > * ipa-icf.c: Add nocf_check attribute in statement hash.
> > > > * recog.c (peep2_attempt): Add REG_CALL_NOCF_CHECK handling.
> > > > * r

RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling

[Tsimbalist, Igor V]

Updated patch, version #3.

Igor


> -Original Message-
> From: Tsimbalist, Igor V
> Sent: Friday, September 29, 2017 4:32 PM
> To: Jeff Law <l...@redhat.com>; gcc-patches@gcc.gnu.org
> Cc: richard.guent...@gmail.com; Tsimbalist, Igor V
> <igor.v.tsimbal...@intel.com>
> Subject: RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> 
> > -Original Message-
> > From: Jeff Law [mailto:l...@redhat.com]
> > Sent: Friday, September 29, 2017 12:44 AM
> > To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> > patc...@gcc.gnu.org
> > Cc: richard.guent...@gmail.com
> > Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> >
> > On 09/19/2017 07:39 AM, Tsimbalist, Igor V wrote:
> > > Here is an updated patch (version #2). The main differences are:
> > >
> > > - Change attribute and option names;
> > > - Add additional parameter to gimple_build_call_from_tree by adding
> > > a
> > type parameter and
> > >   use it 'nocf_check' attribute propagation;
> > > - Reimplement fixes in expand_call_stmt to propagate 'nocf_check'
> > > attribute;
> > > - Consider 'nocf_check' attribute in Identical Code Folding (ICF)
> > > optimization;
> > > - Add warning for type inconsistency regarding 'nocf_check'
> > > attribute;
> > > - Many small fixes;
> > >
> > > gcc/c-family/
> > >   * c-attribs.c (handle_nocf_check_attribute): New function.
> > >   (c_common_attribute_table): Add 'nocf_check' handling.
> > >   * c-common.c (check_missing_format_attribute): New function.
> > >   * c-common.h: Likewise.
> > >
> > > gcc/c/
> > >   * c-typeck.c (convert_for_assignment): Add check for nocf_check
> > >   attribute.
> > >   * gimple-parser.c: Add second argument NULL to
> > >   gimple_build_call_from_tree.
> > >
> > > gcc/cp/
> > >   * typeck.c (convert_for_assignment): Add check for nocf_check
> > >   attribute.
> > >
> > > gcc/
> > >   * cfgexpand.c (expand_call_stmt): Set REG_CALL_NOCF_CHECK for
> > >   call insn.
> > >   * combine.c (distribute_notes): Add REG_CALL_NOCF_CHECK
> > handling.
> > >   * common.opt: Add fcf-protection flag.
> > >   * emit-rtl.c (try_split): Add REG_CALL_NOCF_CHECK handling.
> > >   * flag-types.h: Add enum cf_protection_level.
> > >   * gimple.c (gimple_build_call_from_tree): Add second parameter.
> > >   Add 'nocf_check' attribute propagation to gimple call.
> > >   * gimple.h (gf_mask): Add GF_CALL_NOCF_CHECK.
> > >   (gimple_call_nocf_check_p): New function.
> > >   (gimple_call_set_nocf_check): Likewise.
> > >   * gimplify.c: Add second argument to gimple_build_call_from_tree.
> > >   * ipa-icf.c: Add nocf_check attribute in statement hash.
> > >   * recog.c (peep2_attempt): Add REG_CALL_NOCF_CHECK handling.
> > >   * reg-notes.def: Add REG_NOTE (CALL_NOCF_CHECK).
> > >   * toplev.c (process_options): Add flag_cf_protection handling.
> > >
> > > Is it ok for trunk?
> > >
> > > Thanks,
> > > Igor
> > >
> > >
> >
> >
> > >
> > > diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
> > > index
> > > 0337537..77d1909 100644
> > > --- a/gcc/c-family/c-attribs.c
> > > +++ b/gcc/c-family/c-attribs.c
> > > @@ -65,6 +65,7 @@ static tree handle_asan_odr_indicator_attribute
> > > (tree *, tree, tree, int,  static tree
> > > handle_stack_protect_attribute (tree *, tree, tree, int, bool *);
> > > static tree handle_noinline_attribute (tree *, tree, tree, int, bool
> > > *);  static tree handle_noclone_attribute (tree *, tree, tree, int,
> > > bool *);
> > > +static tree handle_nocf_check_attribute (tree *, tree, tree, int,
> > > +bool *);
> > >  static tree handle_noicf_attribute (tree *, tree, tree, int, bool
> > > *); static tree handle_noipa_attribute (tree *, tree, tree, int,
> > > bool *); static tree handle_leaf_attribute (tree *, tree, tree, int,
> > > bool *); @@ -367,6 +368,8 @@ const struct attribute_spec
> > c_common_attribute_table[] =
> > >{ "patchable_function_entry",  1, 2, true, false, false,
> > > handle_patchable_function_entry_attribute,
> > > false },
> > > +  { "nocf_check",  0, 0, false, true, true,
> > > +   handle_nocf_che

RE: 0002-Part-2.-Document-finstrument-control-flow-and-notrack attribute

[Tsimbalist, Igor V]

> -Original Message-
> From: Sandra Loosemore [mailto:san...@codesourcery.com]
> Sent: Friday, September 29, 2017 6:57 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; 'gcc-
> patc...@gcc.gnu.org' <gcc-patches@gcc.gnu.org>
> Cc: Jeff Law <l...@redhat.com>
> Subject: Re: 0002-Part-2.-Document-finstrument-control-flow-and-notrack
> attribute
> 
> On 09/27/2017 06:27 AM, Tsimbalist, Igor V wrote:
> > Updated version #4.
> >
> > [snip]
> > @@ -11348,6 +11349,31 @@ is used to link a program, the GCC driver
> > automatically links  against @file{libmpxwrappers}.  See also @option{-
> static-libmpxwrappers}.
> >  Enabled by default.
> >
> > +@item -fcf-
> protection==@r{[}full@r{|}branch@r{|}return@r{|}none@r{]}
> > +@opindex fcf-protection
> > +Enable code instrumentation of control-flow transfers to increase
> > +program security by checking that target addresses of control-flow
> > +transfer instructions (such as indirect function call, function
> > +return, indirect jump) are valid.  This prevents diverting the flow
> > +of control to an unexpected target.  This is intended to protect
> > +against such threats as Return-oriented Programming (ROP), and
> > +similarly call/jmp-oriented programming (COP/JOP).
> > +
> > +For all targets, which do not support the @option{-fcf-protection}
> > +option, the option usage results in an error message.
> 
> Please take this sentence out.  It's ungrammatical and verbose and
> unnecessary.

Removed.

> Note that several of the other options described in this section are not
> enabled on all targets either.  E.g., I've just been looking at fixing the 
> nios2
> backend to make -fstack-protector work, and there is nothing in the manual
> to say that GCC issues an error if there's no target support, even though
> that's what it does.
> 
> The patch is OK to commit with that change.

Thanks,
Igor

> -Sandra

RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling

[Tsimbalist, Igor V]

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Friday, September 29, 2017 12:44 AM
> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; gcc-
> patc...@gcc.gnu.org
> Cc: richard.guent...@gmail.com
> Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> 
> On 09/19/2017 07:39 AM, Tsimbalist, Igor V wrote:
> > Here is an updated patch (version #2). The main differences are:
> >
> > - Change attribute and option names;
> > - Add additional parameter to gimple_build_call_from_tree by adding a
> type parameter and
> >   use it 'nocf_check' attribute propagation;
> > - Reimplement fixes in expand_call_stmt to propagate 'nocf_check'
> > attribute;
> > - Consider 'nocf_check' attribute in Identical Code Folding (ICF)
> > optimization;
> > - Add warning for type inconsistency regarding 'nocf_check' attribute;
> > - Many small fixes;
> >
> > gcc/c-family/
> > * c-attribs.c (handle_nocf_check_attribute): New function.
> > (c_common_attribute_table): Add 'nocf_check' handling.
> > * c-common.c (check_missing_format_attribute): New function.
> > * c-common.h: Likewise.
> >
> > gcc/c/
> > * c-typeck.c (convert_for_assignment): Add check for nocf_check
> > attribute.
> > * gimple-parser.c: Add second argument NULL to
> > gimple_build_call_from_tree.
> >
> > gcc/cp/
> > * typeck.c (convert_for_assignment): Add check for nocf_check
> > attribute.
> >
> > gcc/
> > * cfgexpand.c (expand_call_stmt): Set REG_CALL_NOCF_CHECK for
> > call insn.
> > * combine.c (distribute_notes): Add REG_CALL_NOCF_CHECK
> handling.
> > * common.opt: Add fcf-protection flag.
> > * emit-rtl.c (try_split): Add REG_CALL_NOCF_CHECK handling.
> > * flag-types.h: Add enum cf_protection_level.
> > * gimple.c (gimple_build_call_from_tree): Add second parameter.
> > Add 'nocf_check' attribute propagation to gimple call.
> > * gimple.h (gf_mask): Add GF_CALL_NOCF_CHECK.
> > (gimple_call_nocf_check_p): New function.
> > (gimple_call_set_nocf_check): Likewise.
> > * gimplify.c: Add second argument to gimple_build_call_from_tree.
> > * ipa-icf.c: Add nocf_check attribute in statement hash.
> > * recog.c (peep2_attempt): Add REG_CALL_NOCF_CHECK handling.
> > * reg-notes.def: Add REG_NOTE (CALL_NOCF_CHECK).
> > * toplev.c (process_options): Add flag_cf_protection handling.
> >
> > Is it ok for trunk?
> >
> > Thanks,
> > Igor
> >
> >
> 
> 
> >
> > diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c index
> > 0337537..77d1909 100644
> > --- a/gcc/c-family/c-attribs.c
> > +++ b/gcc/c-family/c-attribs.c
> > @@ -65,6 +65,7 @@ static tree handle_asan_odr_indicator_attribute
> > (tree *, tree, tree, int,  static tree handle_stack_protect_attribute
> > (tree *, tree, tree, int, bool *);  static tree
> > handle_noinline_attribute (tree *, tree, tree, int, bool *);  static
> > tree handle_noclone_attribute (tree *, tree, tree, int, bool *);
> > +static tree handle_nocf_check_attribute (tree *, tree, tree, int,
> > +bool *);
> >  static tree handle_noicf_attribute (tree *, tree, tree, int, bool *);
> > static tree handle_noipa_attribute (tree *, tree, tree, int, bool *);
> > static tree handle_leaf_attribute (tree *, tree, tree, int, bool *);
> > @@ -367,6 +368,8 @@ const struct attribute_spec
> c_common_attribute_table[] =
> >{ "patchable_function_entry",1, 2, true, false, false,
> >   handle_patchable_function_entry_attribute,
> >   false },
> > +  { "nocf_check",0, 0, false, true, true,
> > + handle_nocf_check_attribute, false },
> >{ NULL, 0, 0, false, false, false, NULL, false }
> >  };
> >
> > @@ -783,6 +786,26 @@ handle_noclone_attribute (tree *node, tree
> name,
> >return NULL_TREE;
> >  }
> >
> > +/* Handle a "nocf_check" attribute; arguments as in
> > +   struct attribute_spec.handler.  */
> > +
> > +static tree
> > +handle_nocf_check_attribute (tree *node, tree name,
> > + tree ARG_UNUSED (args),
> > + int ARG_UNUSED (flags), bool *no_add_attrs) {
> > +  if (TREE_CODE (*node) != FUNCTION_TYPE
> > +  && TREE_CODE (*node) != METHOD_TYPE
> > +  && TREE_CODE (*node) != FIELD_DECL
> > +  &&