On Wed, May 1, 2013 at 2:00 PM, Jeff Law <l...@redhat.com> wrote: > On 04/26/2013 10:45 AM, Han Shen(沈涵) wrote: >> >> Hi, I'd like to ping the patch '-fstack-protector-strong': >> >> - http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00945.html >> Add a new option '-fstack-protector-strong' to protect only >> stack-smashing-vulnerable functions. >> >> Thanks, >> H. >> > > In cfgexpand.c, please make the constants an enum rather than #define. The > former is visible in a debugger, the latter generally isn't. If you could > order them numerically, it'd be helpful as well. Done. > > > - if (flag_stack_protect == 2) > + if (flag_stack_protect == SPCT_FLAG_ALL || > + flag_stack_protect == SPCT_FLAG_STRONG) > > GNU coding standards mandate the operator go on the next line when splitting > lines. So something like > > if (flag_stack_protect == SPCT_FLAG_ALL > || flag_stack_protect == SPCT_FLAG_STRONG) > > > Similarly in expand_used_vars.
Thanks, done. (New patched replied in the original thread.) > > How do you plan on handling Florian's retslot issue? Are you going to scan > the gimple looking for suitable calls? How do you avoid instrumentation in > the callee for that case? > > I find myself wondering if you'd be better off scanning the gimple > representation looking for ADDR_EXPR operations, then peeking at the > argument to see if it's part of the local frame or something higher up. > > Prsumably you catch cases where the ABI mandates that certain arguments be > copied by the caller and the address passed to the callee? What about the > opposite (and yes, both exist). See TARGET_PASS_BY_REFERENCE, > TARGET_CALLEE_COPIES. I suspect scanning the gimple code is much more > likely to pick up this stuff. Yeah, I see. That's are good suggestions. I'll amend these (probably minor) cases in another patch - if no objection to that - which needs a good testing/performance/security measurement. > > Generally I like the idea of getting better stack smashing coverage without > the penalty of stack-protector-all. > > > Jeff Han