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

[Matthieu Monrocq]

On Wed, Aug 22, 2012 at 8:36 PM, Chris Lattner <clattner at apple.com> wrote:

> 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".
>
>
Related to this, in the company I work in we experimented with a
lightweight memory leak detector approach (which relied on substituting the
malloc implementation by LD_PRELOAD) and the consensus was that we could
afford to run our test servers with a x2 penalty, but not much more. The
problem is not that the servers answer a bit more slowly, it's that if they
are slower you need more of them to cope with the same traffic. We never
quite really managed to get this level of performance though (got stuck at
x4/x5) and the project aborted.

I think the approach suffered from not being tunable enough, since all
malloc related traffic was kept around, even though most memory was managed
by RAII constructs (std::string, std::vector...) and thus could not leak by
design; I hope that by getting these checks into the compiler the optimizer
(LLVM) will be able to discard a lot of them.


> 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
>

-- Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120825/555966d6/attachment.html>