<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 20, 2017, at 11:33 PM, Justin Bogner <<a href="mailto:mail@justinbogner.com" class="">mail@justinbogner.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">George Burgess IV via cfe-dev <</span><a href="mailto:cfe-dev@lists.llvm.org" style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">cfe-dev@lists.llvm.org</a><span style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">> writes:</span><br style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">Hi,<br class=""><br class=""><blockquote type="cite" class="">AFAICT, and please let me know if I've missed something here,<br class="">@llvm.objectsize always conservatively returns "I don't know" (i.e<br class="">-1) at -O0<br class=""></blockquote><br class="">Yup. The object-size sanitizer lowers directly to @llvm.objectsize<br class="">(bypassing clang's __builtin_object_size evaluator, which is the<br class="">right thing to do here), and the only places we try to lower<br class="">@llvm.objectsize to a non-default value, to my knowledge, are<br class="">in InstCombine and CodeGenPrepare. Looks like both of those<br class="">are disabled on -O0.<br class=""><br class="">As you mentioned, if we did decide that we should try to<br class="">lower @llvm.objectsize calls more aggressively in -O0, I'd<br class="">imagine we'd still end up handing back -1 in ~99% of cases.<br class="">(With the remaining 1% looking something like:<br class=""><br class="">struct Foo {int i;};<br class="">char c;<br class="">int bar() { return reinterpret_cast<Foo *>(&c)->i; } // error: c is<br class="">too small, ...<br class="">)<br class=""></blockquote><br style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">How reasonable would it be to do something simpler that catches this in</span><br style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">particular? Though, ISTM this is probably obvious enough that we could</span><br style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">catch it at compile time.</span><br style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>It would be feasible to warn at compile-time for simple cases like this one, or the one in [1]. We currently don't: at least, not in the static analyzer or with -Wall -Wextra.</div></div><div><br class=""></div><div>That said, I'm not sure that this "simple" type of violation is commonplace. All of the -fsanitize=object-size violations I've seen involve either heap allocation or cross-TU calls. I imagine that these bugs would be hard to diagnose at compile-time.</div><div><br class=""></div><div>[1] <a href="https://developer.apple.com/documentation/code_diagnostics/undefined_behavior_sanitizer/invalid_object_size" class="">https://developer.apple.com/documentation/code_diagnostics/undefined_behavior_sanitizer/invalid_object_size</a></div><div><br class=""></div><div>vedant</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">So, unless I'm missing something, I think this is a pure win for<br class="">ubsan in -O0. I'm in favor of it.<br class=""><br class="">Thank you!<br class="">George<br class=""><br class="">On Tue, Jun 20, 2017 at 4:57 PM, Vedant Kumar via cfe-dev<br class=""><<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""><blockquote type="cite" class="">UBSan has an object size check (-fsanitize=object-size) which can determine<br class="">when an object is not large enough to represent a value of its type. The<br class="">check uses the @llvm.objectsize intrinsic to determine the size of objects.<br class=""><br class="">AFAICT, and please let me know if I've missed something here,<br class="">@llvm.objectsize always conservatively returns "I don't know" (i.e -1) at<br class="">-O0, which means that it can't catch any issues at -O0. This is a problem<br class="">because there is a substantial compile-time cost to enabling the object size<br class="">check in debug builds. It seems unlikely that we can make @llvm.objectsize<br class="">more precise at -O0 without regressing compile time and the debugging<br class="">experience in other ways.<br class=""><br class="">So, I'm proposing that we disable ubsan's object size check at -O0. This<br class="">will speed up debug builds without compromising on diagnostic quality. E.g I<br class="">measured a 26% decrease in the compile time for X86FastISel.cpp with this<br class="">change, and a 32% decrease in the *.o size:<br class=""><br class="">No ubsan [1]<br class="">-----------------<br class="">Average compile time: 5.27 s<br class="">X86FastISel.cpp.o size: 3.06 MB<br class=""><br class="">Ubsan [2]<br class="">-------------<br class="">Average compile time: 9.49 s<br class="">X86FastISel.cpp.o size: 8.93 MB<br class=""><br class="">Ubsan without the object size check [3]<br class="">----------------------------------------------------<br class="">Average compile time: 6.99 s<br class="">X86FastISel.cpp.o size: 6.06 MB<br class=""><br class=""><br class="">There's reason to expect similar compile-time / binary size savings with<br class="">other *.cpp files. The object size check is in the same category of checks<br class="">as the null check and the alignment check. This group of checks accounts for<br class="">the vast majority of checks inserted by ubsan (over 90% in some macOS apps),<br class="">so any savings here would be helpful.<br class=""><br class="">Any objections? Anyone else in favor?<br class=""><br class="">thanks,<br class="">vedant<br class=""><br class="">[1] -O0 -g<br class="">[2] -O0 -g -fsanitize=undefined -fno-sanitize-recover=all<br class="">-fno-sanitize=vptr,function<br class="">[3] -O0 -g -fsanitize=undefined -fno-sanitize-recover=all<br class="">-fno-sanitize=vptr,function,object-size<br class=""><br class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""><br class=""></blockquote>_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></blockquote></div></blockquote></div><br class=""></body></html>