https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856
--- Comment #13 from Josh Triplett <josh at joshtriplett dot org> --- (In reply to PaX Team from comment #12) > 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. That sounds really plausible to me. GCC's constant propagation seems likely to do *at least* as well as Sparse does, if not better. (As long as you have optimizations turned on, anyway.) Note that in addition to complaining if *any* exit to the function doesn't have the correct "out" value, you also need to complain if calls to functions with the context attribute don't have the necessary "in" value. You may want to make that a separate warning option, though, as that option tends to force adding annotations to far more functions. This approach won't necessarily provide the "different contexts for basic block" warning that Sparse has, but I don't necessarily think we need that; we only care about running a block with different locks if that block actually wants a lock. (Some prototypes in Sparse once provided a separate attribute for use on structure fields, that specified the lock you have to hold to touch that field; that could act as another assertion on the context.)
