Problem: Currently we have has_hardened(), has_pic(), has_ssp(), has_ssp_all() and has_pie() in flag-o-matic.eclass, which are intended to provide ebuilds with a way of working out what hardened stuff is on in the compiler. However, has_hardened() only says whether the USE=hardened was set when the compiler was emerged, has_pie() simply doesn't work, has_pic() isn't particularly accurate as it doesn't take account of fPIE (indeed since the hardened specs only ever switch on PIE automatically, has_pic's very existence is misleading), and the has_ssp() functions depend on the compiler setting the __SSP__/__SSP_ALL__ macros, which his broken in the current stable x86 compiler (see bug #93011). We need a reliable method of finding out what stuff the compiler is configured to do that is different from a standard vanilla compiler. First, it seems the best place to provide ways of determining the compiler state is toolchain-funcs rather than flag-o-matic. The method of checking compiler macro definitions isn't useful. The only reliable way to check what the compiler is up to, is to check the active compiler specs. To be attached is a diff to toolchain-funcs.eclass which adds a few functions: gcc-specs() a support function to determine the name of the active SPECS file gcc-specs-pie() return TRUE if the active specs build PIEs by default gcc-specs-ssp() return TRUE if the active specs build SSP by default gcc-specs-hard() return TRUE if the active specs set relro/now. The method used in my suggestion is to look for the '{!<disableflag>:' string in the active specs file; somewhat rough but it works. As the toolchain changes, toolchain-funcs.eclass obviously tracks to maintain compatibility. The active specs file is obtained from 'gcc -v', using the last specs file reported (note; when GCC_SPECS is set, 'gcc -v' reports two specs files and it's the last one that is actually active). This method is independent of how GCC_SPECS is managed (i.e. it's independent of bug #96162). I did look at just doing 'gcc -dumpspecs' but that always returns the contents of the default .../specs file, not the one actually in action at the time. Another method could be to check the /etc/env.d/gcc/config{-<target>} and friends. Personally I prefer to rely on as little other stuff as possible, and 'gcc -v' leads to all the necessary information. Note; these do absolutely nothing with CFLAGS (unlike the has_pic/pie/ssp functions). Such flag stuff is the domain of flag-o-matic. Ultimately, if this is agreeable, the misleading and unreliable has_hardened/pic/pie/ssp/ssp_all() functions can be deprecated, ebuilds updated to use the above functions and normal flag-o-matic CFLAGS editing.
Created attachment 61344 [details, diff] patch to add gcc-specs functions to toolchain-funcs.eclass
Created attachment 61351 [details, diff] Patch with more robust specs files parsing After some discussion on IRC, some changes: 1) Now parses specs more robustly, locating and extracting directive definitions. from multiple spec files correctly. 2) split gcc-specs-hard into gcc-specs-now and gcc-specs-relro
See bug #100974, tracker for ebuild/eclass updates.
