<br><br><div class="gmail_quote">On Tue, Jan 24, 2012 at 1:23 AM, Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr">baldrick@free.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Kostya,<br>
<div class="im"><br>
> [resurrecting an old mail thread about AddressSanitizer false positive caused by<br>
> load widening]<br>
><br>
> Once the Attribute::AddressSafety is set by clang (a separate patch), fixing<br>
> this bug may look as simple as this:<br>
<br></div></blockquote><div>Hi Duncan,  </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
</div>I don't get the point of an attribute.  There's plenty of code out there<br>
that does wide loads like this directly (without them being created by the<br>
optimizers) since, </blockquote><div><br></div><div>You mean, the source code that e.g. loads 8 bytes, where up to 7 bytes might be out of array bounds?  </div><div>Yes, we've seen quite a bit of such code. </div><div>
<br></div><div>First, such code often appears in libc, mostly in hand-written assembly (e.g. strlen), and valgrind/memcheck has a lot of trouble dealing with it</div><div>(it basically has to intercept all such functions, which does not work when such functions are inlined, so valgrind does not properly work with O2-compiled binaries). </div>
<div>asan does not care about it (yet) because it does not instrument libc. </div><div><br></div><div>Second, we also seen such hacks in regular C/C++ code (usually, in codecs or compression code). </div><div>Strictly speaking -- all these cases are bugs, according to either C or C++ standard, and asan does not impose more restrictions than the standard. </div>
<div>Note, that the hacks like these hurt not only address safety checkers like asan/memcheck/drmemory/SAFEcode/etc, but also race detectors like tsan/helgrind/drd/etc.</div><div><br></div><div>We still have lots of code with these intentional OOB accesses and we want to test it. </div>
<div>In most cases I've met so far, the developers decided to actually fix the bugs according to the C++ standard and require the memory allocation to have up to 7 extra bytes. </div><div>I do expect that sometimes this is impossible or undesirable. </div>
<div>Then the solution would be to use __attribute__((address_safety)) to avoid instrumenting the tricky pieces of code. </div><div><br></div><div>--kcc </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
just like the optimizers, they know it is safe and a win.<br>
The attribute won't help them.  It looks like a way of just hiding the real<br>
problem, which seems to be that address sanitizer is overly strict.<br>
<br></blockquote></div>