On Wed, Apr 18, 2018 at 5:32 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
> On Wed, Apr 18, 2018 at 2:09 PM, Jakub Jelinek <ja...@redhat.com> wrote:
>> 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:
>
> Yes, this is what I think should be the most appropriate approach.
>
> Uros.
>
>> 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
>>
>>
>>         Jakub

Looks good to me.

Thanks.

-- 
H.J.

Reply via email to