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.
- 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.
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.
Generally I like the idea of getting better stack smashing coverage
without the penalty of stack-protector-all.
Jeff