[cfe-dev] [RFC] Extending and improving Clang's undefined behavior checking

[Chris Lattner]

On Aug 22, 2012, at 10:50 AM, John Criswell <criswell at illinois.edu> wrote:
>> The current implementation doesn't, but that's because its reporting mechanism is currently hard coded to "abort()".  It could (in principle, not saying this is important) be extended to report better source-level diagnostics.
> 
> You're right about the call to abort() and adding better diagnostics, but the problem goes deeper than that.  Most run-time checks (such as ASan's, SAFECode's, and SoftBound's) can usually tell the user *which* instruction is causing memory corruption and, in some cases, which variables are involved.  Stack canaries, I think, can only report which return instruction detected the corruption; it can't tell you which previously executed instruction actually caused the corruption.

Sure, I understand how stack canaries work.

>> Right.  Some would be on by default with -fcatch-undefined-behavior, some would be opt-inable with -fcatch-undefined-behavior=something-specific
> 
> Do you have any opinions on my "undefined behavior levels" idea?  In most cases, I don't think users want to fiddle around with a whole bunch of options for a whole bunch of checks that they don't understand; I think a dial that trades off run-time performance for more strict checking (in the same way that -O is a dial that trades off compile-time for faster code) is easier to use.

I agree with you that only experts (or compiler hackers :) should be expected to twiddle detailed options.  I think that there are a few really important levels that we should focus on in order of priority:

1. The "on by default" configuration.  Checks that are cheap enough and important enough to be included even in production builds, like certain cases of stack canaries and "fortify source" are now.

2. The default -fcatch-undefined-behavior configuration.  This should be an obvious blend of checks that doesn't cause a tortuous performance hit (I think valgrind's 20x hit would be too much, but maybe 2-4x would be ok) but that find a lot of bugs that people care about.  We probably don't want to include checks for implementation-defined behavior in this, because that is likely to find a lot of bugs that "people don't care about".

3. Specific modes of -fcatch-undefined-behavior that are intended to find certain classes of problems.  If I've got a memory corruption issue that I'm trying to debug and can't figure out, I may be willing to throw arbitrary amounts of runtime and compile time at the problem.  A 20x slowdown would be fine.  We'd want a high level flag like "-fcatch-undefined-behavior=extensive-memory-checks" or something like that.

4. The hacker/tweaker case of wanting to enable/disable individual checks, tweak parameters of checks, etc.

-Chris