<div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 5, 2012 at 2:40 AM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank" class="cremed">kcc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+<a href="mailto:samsonov@google.com" target="_blank" class="cremed">samsonov@google.com</a><br><br><div class="gmail_quote">
<div class="im">On Wed, Sep 5, 2012 at 1:12 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank" class="cremed">chandlerc@google.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="gmail_extra"><div class="gmail_quote"><div>On Tue, Sep 4, 2012 at 4:41 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank" class="cremed">chandlerc@google.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Nadav, super excited about this.<div><br></div><div>Recently, we tried to roll out some significant improvements to GCC's stack slot re-use, and discovered a really terrifying number of bugs in user code stemming from this. I would like to make sure that when using tools like ASan, this logic is disabled, and ASan can correctly detect code using an alloca after its lifetime has ended. Without this, it will be very hard to track down mis-compiles introduced here. Adding Kostya as I'm not familiar with the exact current state of ASan and lifetime of alloca instrumentation.</div>


</blockquote><div><br></div></div><div>Having read the discussion more carefully when we hit lots of user bugs surrounding this, I have more information.</div><div><br></div><div>The problem stems from re-use of locals after their lifetime ends. These won't show up often until we teach Clang to emit the lifetime intrinsics for those locals. Once we do, your pass will cause a very large amount of code to blow up. It's a good thing too, as that code is *broken*.</div>


<div><br></div><div>We need to teach ASan to use the lifetime markers to catch use-after-lifetime-ends bugs first IMO, and *then* enable this pass and the lifetime markers coming from Clang. That way we will already have the tools to find these bugs quickly and accurately.</div>

</div></div></blockquote><div><br></div></div><div>This is in our TODO, although, unfortunately, I am not sure when we will get to it. </div><div>Perhaps in October.</div><div><a href="http://code.google.com/p/address-sanitizer/issues/detail?id=83&" target="_blank" class="cremed">http://code.google.com/p/address-sanitizer/issues/detail?id=83&</a></div>
</div></blockquote><div><br></div><div>I'm hoping that those interested in the optimization could potentially contribute help toward this goal. =]</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>We probably will also need to disable this particular optimization for functions that have the ASan attribute set.</div></div></div></blockquote><div><br></div></div><div>Hm. This is happening in the CodGen, i.e. after asan, right? </div>

<div>asan merges all Alloca instructions into a single large Alloca, so under asan this optimization will be automatically disabled anyway. No? </div></div></blockquote><div><br></div><div>Ah, nice. I had forgotten about that aspect of the instrumentation pass.</div>
</div></div>