https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856
--- Comment #14 from PaX Team <pageexec at gmail dot com> --- (In reply to Josh Triplett from comment #13) > 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 optimizations are not actually necessary for the scheme to work, it just means that the check(s) will have to do more work as you'll get a phi and have to traverse back the data flow to see if any unexpected values can end up there (optimizations basically do this data flow tracking for free and result in dead code elimination thus making it easier on the checks). in fact i expect that this will already happen on real linux code so the plugin will have to handle this case 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. sure, it's easy enough to inject more checks than just at the function return sites, i just wanted to validate my idea first then do the make-it-usable part which includes increased coverage too. > You may want to make that a separate warning option, though, as that option > tends to force adding annotations to far more functions. actually one idea for the future is to extend the plugin to be IPA then LTO aware so that it can discover the acquire/release properties itself based on an initial set of 'seed' functions that have to be marked by hand (and which already are i guess, all the direct callers of __context__ basically). we have experience in this area with the size overflow and other plugins, so the infrastructure is there already (albeit the LTO part is held up by PR61311). > 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; can you give me an example of this? the thing is, my approach tracks the context with statement granularity so if you can tell the compiler where you expect specific states (such as the context attr on callees) checks can be inserted there easily, down to individual statements (say, the structure field accesses you mentioned).
