https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856
--- Comment #12 from PaX Team <pageexec at gmail dot com> --- 1. there's a (linux) kernel-hardening effort of late that among others will try to upstream the PaX gcc plugin infrastructure along with some plugins, so the checker one could be added to that list (but it wasn't part of the initial plan). you should probably continue this thread on that list instead as i doubt many kernel devs follow the gcc bugzilla ;). 2. as for my idea, it's simple: track the context via an artificially injected local integer variable (one per context if you want context sensitivity) and initialize it to the 'in' attr parameter or 0 otherwise then adjust its value on function calls that affect it based on the callee's context attribute. at the end compare the variable against the 'out' attr parameter (or 0) and complain on a mismatch (in my proof-of-concept i just called builtin_trap on a mismatch). now where gcc comes in is that it'll do constant propagation, DCE, etc for free so the final check either gets removed by dead code elimination (the locking is correct) or we detected a locking problem and can even determine the bad path(s). using this simple method on Josh's test file there're no false positives or false negatives. i'll work it into something usable (actual reports instead of having to check for leftover builtin_traps) and release it in PaX then linux can pick it up when the time comes.