> -----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

Reply via email to