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 <cet.h> 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.
Jakub
