> -----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 <ucontext.h>. > > > > 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