In LLVM this will also be non-trivial,
but I expect it to be counter-productive because asan will inhibit many
optimizations.
Easier to just run with -O0 periodically. I know this is actually not easy
at all. :(
What we can and should do is to teach llvm to emit a proper trap.
Consider my example:
int bar() { return 3; }
int foo() {
int x[3] = {1, 2, 3};
return x[bar()];
}
% clang -c -O2 sbo.cc -emit-llvm -o - -S
define i32 @_Z3foov() #0 {
entry:
ret i32 undef
}
Here, if you use -O2, the compiler will optimize the illegal code into ret
i32 undef,
but it will not crash, sadly. Maybe it should.
Same thing in your example:
%call = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x
i8], [4 x i8]* @.str, i64 0, i64 0), i32 undef)
I'd suggest you to either start a discussion at llvm-dev or file a LLVM
bug.
BTW, -fsanitize=bounds will catch these bugs.
--kcc
On Sun, Jan 17, 2016 at 3:24 AM, Yuri Gribov <tetra2...@gmail.com> wrote:
> On Sun, Jan 17, 2016 at 11:56 AM, John Regehr <john.reg...@gmail.com>
> wrote:
> > Would it be possible to add an option specifying that the asan
> > instrumentation is done before running any optimizers? Presumably this
> would
> > offer an interesting tradeoff where there transparent bugs aren't missed
> but
> > performance is still much better than -O0.
>
> This isn't so easy with GCC which tends to start "optimizing" code
> long before GIMPLE. AFAIR in my case erroneous memory access was
> removed during parsing.
>
> > On Friday, January 15, 2016 at 5:58:36 PM UTC+1, kcc wrote:
> >>
> >> +john
> >>
> >> Yea, if optimizations get rid of the buggy code before asan gets a
> chance
> >> to instrument it -- the bug will be missed.
> >> We've seen it before in many *trivial* examples.
> >> It's unclear how many bugs we miss this way; some for sure.
> >>
> >> On Fri, Jan 15, 2016 at 8:51 AM, Hanno Böck <ha...@hboeck.de> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I just saw this tweet by John Regehr:
> >>> https://twitter.com/johnregehr/status/688033344580399104
> >>>
> >>> He found a code example with a pretty obvious out of bounds stack read
> >>> that asan doesn't catch with -O or -O2 (equivalent). I checked this
> >>> with both current gcc and clang.
> >>>
> >>> This is a stripped down example:
> >>> int main() {
> >>> int b[1] = {0};
> >>> int a=-1;
> >>> printf("%i\n", b[a]);
> >>> }
> >>>
> >>>
> >>> I am a bit surprised, because this looks like a poster child example of
> >>> the kind of bug asan can find. But somehow the optimization
> >>> seems to break the asan check here.
> >>>
> >>> I now wonder how many bugs keep being hidden because of this, as -O2 is
> >>> a pretty common default setting for compilations.
> >>>
> >>>
> >>> --
> >>> Hanno Böck
> >>> http://hboeck.de/
> >>>
> >>> mail/jabber: ha...@hboeck.de
> >>> GPG: BBB51E42
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups
> >>> "address-sanitizer" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> an
> >>> email to address-saniti...@googlegroups.com.
> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "address-sanitizer" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to address-sanitizer+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "address-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to address-sanitizer+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
