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