[cfe-dev] -fcatch-undefined-behavior testing

[Török Edwin]

On 2009-12-16 20:12, Mike Stump wrote:
> On Dec 16, 2009, at 3:39 AM, Daniel Dunbar wrote:
>   
>> Have you considered running this on an LLVM nightly test run?
>>     
>
> Love to see the results; my email was to solicit others into trying the feature out on their favorite code.
>
> Also, I guess I should say, if people have undefined behavior that they would just love to see runtime checks for, maybe to catch portability problems, or to catch security problems or just random bugs in code, I've love to hear the ideas.
>   

Well some of the ideas I have would overlap with what SAFEcode already does.

Ideally it should catch all the undefined behavior that would cause
different behavior when program is compiled with -O0 vs compiled with
-O2. Or in other words, any undefined behavior that could break (the
user's expectations) due to compiler optimizations.
That "idea" is too vague to be useful, so below are some specific ideas,
some already crash at runtime but a better error message
would be very useful.

A general idea first: please allow for individual tests to be turned
on/off, for example I may want to test only for
array overflows, only for shift overflows, etc.
Or if I compile with -fno-strict-aliasing I wouldn't care about aliasing
violations, etc.

1. support something similar to gcc's "-fmudflapth":
  It is useful on occasion when valgrind can't find errors (such as
overrunning a stack allocated buffer). You already do something similar,
however I'd be interested to catch bugs when the buffer (of constant
size) is declared in one function, and the buggy store/load is in
another function.
2. alignment testing
 This is something I haven't found a tool for. Especially important for
sparc, but thats needs a sparc CPU for testing.
It'd be nice if we could catch these bugs by running on x86, and
assuming sparc alignment rules. Even on x86, vectorized variables need
to be aligned, or it crashes.
3. pointer overflows, undefined behavior in userspace
4. aliasing rule violations via casts
 Although LLVM doesn't have TBAA yet, clang could catch some TBAA
errors, when the dynamic type of a casted value doesn't match
5. other aliasing violations
 - restrict qualifier not obeyed (i.e. a noalias pointer indeed aliases
something)
 - two pointers have equal value, yet according to aliasing rules they
never alias (for example overflowing from one struct field to another)
6. pure/const qualifier checks
7. calling convention mismatches
8. noreturn that returns
9. division by zero due to overflow (32-bit division of -2147483648 by -1)
10.  Access to a variable from multiple threads without proper
locking/atomic instructions
11. weak symbols with an initializer, overriden  with another
initializer at link time (optimizer may assume the  initial value it has
seen)
12. use of uninitialized variable
13. calling function using wrong prototype (for example library compiled
with certain flags, function has 5 params, user
compiles with other flags, function has 4 params. At runtime it will
crash/misbehave for C.
Even for C++ its a problem if structures have different
layout/elements). The types' structure should match, including pointed
to types

I had a list with some more ideas, but I can't find that file right now,
if I find it, I'll follow up.

Best regards,
--Edwin