In particular, on specs where SSP is not defaulted (vanilla, hardenednossp and hardenednopiessp), I see the following with a vanilla 3.4.4 compiler: ~ # echo | gcc -dM -E -fstack-protector - | grep SSP #define __SSP__ 1 #define __SSP_ALL__ 2 which is wrong; it should only show __SSP__ not __SSP_ALL__. The same is true for all the compiler versions with split specs (some don't have the SSP macros so it's not so easy to tell). The culprit this bit of the *cc1: rule, which appears in the vanilla and nossp specs: %{!nostdlib: %{fstack-protector: -fstack-protector %{!D_LIBC: %{!D_LIBC_REENTRANT: %{!fno-stack-protector-all:-fstack-protector-all} } } } } Note that the trigger 'fstack-protector:' instead of '!fno-stackprotector:' (which is what the hardened and nopie specs have), where as the '!fno-stack-protector-all:' trigger is unchanged. This means that for example when setting -fstack-protector on a vanilla compiler, you automatically get -fstack-protector-all as well, which is wrong. I've worked up a change to the piepatches for 3.4.4, where these bits of the specs are built, so that on the nossp compilers the spec is: %{!nostdlib: %{fstack-protector: -fstack-protector %{!D_LIBC: %{!D_LIBC_REENTRANT: %{fstack-protector-all: -fstack-protector-all} } } } } I'll attach the changes to this bug (they're also at http://dev.gentoo.org/~kevquinn/toolchain ). If we agree I'm not talking garbage and it's a fix worth doing, I'll work up changes for the other patchsets.
Created attachment 67593 [details, diff] Patch to apply after src_unpack(), for testing
Created attachment 67594 [details, diff] Updated component of piepatches
The piepatches had this intentionally: a. hardened and nopie specs enable both flags b. vanilla and nossp specs enable both if fstack-protector is enabled if you don't like the above "defaults" change it, but you have to warn everyone that after your change it is not enough to use -fstack-protector, you have to use both of them to get full protection enabled c. __SSP__ and __SSP_ALL__ are parts I never touched (are done in the ssp patch), correct would be to have them defined only if the appropiate option is enabled currently they are defined all the time (at least on splitted specs).
I wondered if that might be the case; otherwise it would be easier simply to not add the ssp switch stuff into the vanilla/-nossp specs at all. It means that the vanilla compiler doesn't behave the way a non-split-spec non-hardened compiler behaves (which means it isn't exactly "vanilla"). You end up with a situation in which the only way to get the vanilla compiler to do ssp but not ssp-all is to do: gcc -fstack-protector -fno-stack-protector-all which is counter-intuitive. re. (c) I think the macros are defined properly. You get __SSP__ defined if -fstack-protector is enabled, and __SSP_ALL__ if -fstack-protector-all is enabled - whether they're enabled via command line options or options set via specs. Since the specs "auto-upgrade" -fstack-protector to -fstack-protector-all, then the appearance of __SSP_ALL__ is correct. I certainly wouldn't want to suppress __SSP_ALL__ just because it was enabled via specs rather than the command line. I think we have a real problem, since unless I've missed something, non-hardened users generally get split specs as well (condition for not getting them seems to be setting SPLIT_SPECS to "false" or to have 'nopie' in USE).
it has also a "historical" reason being like, the first releases of the ssp patch didn't have ssp-all at all, later when this was added, I considered having the "old" behaviour using only 1 flag to enable/disable better (although you are right that it is not quite vanilla, I don't quite understand though the need to use vanilla specs and the user specifying -fstack-protector, this was much discussed and noone will l currently tell you to add -fstack-protector to CFLAGS, everyone will propose you to remove it from there and use the hardened specs. Any of these changes will have to be done also in sync w/ the related eclass
feel free to make these changes yourself in the 3.4 sources ... just lemme know when you do so i can push them out
SpanKY - just committed. Changed file w.r.t. 3.4.5 is gcc/3.4.6/pie/def/01_all_gcc-3.4.6-v8.7.7-pie-generic-default.patch Please bump gcc-3.4.6 for this and bug #74457 (whose change is in ssp/protector.c); thanks :)
ok; sys-devel/gcc-3.4.6-r2 is in, with this fix
