<br><br><div class="gmail_quote">On Wed, Aug 22, 2012 at 8:36 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Aug 22, 2012, at 10:50 AM, John Criswell <<a href="mailto:criswell@illinois.edu">criswell@illinois.edu</a>> wrote:<br>
>> 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.<br>

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

<br>
</div>Sure, I understand how stack canaries work.<br>
<div class="im"><br>
>> Right.  Some would be on by default with -fcatch-undefined-behavior, some would be opt-inable with -fcatch-undefined-behavior=something-specific<br>
><br>
> 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.<br>

<br>
</div>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:<br>
<br>
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.<br>

<br>
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".<br>

<br></blockquote><div><br>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.<br>
<br>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.<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

<br>
4. The hacker/tweaker case of wanting to enable/disable individual checks, tweak parameters of checks, etc.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Chris</font></span><br></blockquote><div><br>-- Matthieu <br></div></div>