RE: [PATCH 09/22] Enable building libbacktrace with Intel CET

["Tsimbalist, Igor V" <igor dot v dot tsimbalist at intel dot com>]

> -----Original Message-----
> From: Ian Lance Taylor [mailto:ian@airs.com]
> Sent: Friday, October 13, 2017 1:59 AM
> To: Tsimbalist, Igor V <igor.v.tsimbalist@intel.com>
> Cc: gcc-patches@gcc.gnu.org; Jeff Law <law@redhat.com>
> Subject: Re: [PATCH 09/22] Enable building libbacktrace with Intel CET
> 
> "Tsimbalist, Igor V" <igor.v.tsimbalist@intel.com> writes:
> 
> > Enable building libbacktrace with CET options.
> >
> > libbacktrace/
> > 	* configure.ac: Add CET_FLAGS to EXTRA_FLAGS.
> > 	* aclocal.m4: Regenerate.
> > 	* Makefile.in: Likewise.
> > 	* configure: Likewise.
> 
> > +if test x$enable_cet = xyes; then
> > +  CET_FLAGS="-fcf-protection -mcet -include cet.h"
> > +fi
> 
> Is this really right?  Why the -include option?  CET protection sounds like it
> should work for any language, but -include is C-specific and doesn't seem to
> have anything to do with code generation.

This file is included to simplify building a library that might have assembler files.
This is an auxiliary file to automate creation of a special section in an output object
file. Without it every assembler file has to be modified by hand to include a special
section. This "-include cet.h " option is specified at a high level to not bother if a
library has or does not have assembler files. The option either has no effect if
all source files are C/C++ or used only for assembler file processing. The file itself
has an assembler code. The same code is generated by the compiler for each
input C/C++/etc. files.

In real life a user who is going to write an assemble code and have it CET compatible
has to add a special section to mark the object file as CET compatible.

Igor

> Of course, for libbacktrace, that is a generated file.  The patch to
> libbacktrace/configure.ac is fine if the general approach is approved.
> 
> Ian