> -----Original Message----- > From: Ian Lance Taylor [mailto:i...@airs.com] > Sent: Friday, October 13, 2017 1:59 AM > To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com> > Cc: gcc-patches@gcc.gnu.org; Jeff Law <l...@redhat.com> > Subject: Re: [PATCH 09/22] Enable building libbacktrace with Intel CET > > "Tsimbalist, Igor V" <igor.v.tsimbal...@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
