[PATCH] Add a no_sanitize_vptr function attribute.

Richard Smith richard at metafoo.co.uk
Thu Apr 16 18:05:40 PDT 2015


On Thu, Apr 16, 2015 at 5:28 PM, Arthur O'Dwyer <
arthur.j.odwyer+phab+github at gmail.com> wrote:

> ================
> Comment at: test/CodeGen/no-sanitize-vtpr.cpp:1
> @@ +1,2 @@
> +// Verify ubsan doesn't emit checks for functions with the
> no_sanitize_vptr attribute.
> +// RUN: %clang_cc1 -fsanitize=vptr -emit-llvm %s -o - | FileCheck %s
> ----------------
> Typo in the name of this test: `vtpr` should be `vptr`.
>
> ================
> Comment at: test/CodeGen/no-sanitize-vtpr.cpp:17
> @@ +16,3 @@
> +  // CHECK-NOT: call void @__ubsan_handle_dynamic_type_cache_miss
> +  Foo* foo = static_cast<Foo*>(&bar); // down-casting
> +  // CHECK: ret void
> ----------------
> If I understand the feature correctly, the idea is that UBSan inserts
> runtime checks for various undefined behaviors, including the undefined
> behavior of down-casting `Bar*` to `Foo*` in the case that the original
> `Bar*` doesn't actually point to an instance of `Foo`.
>
> However, this particular test case is statically detectable as undefined
> behavior, isn't it?


There could have been a placement new between the creation of bar and the
static_cast, changing its dynamic type from Bar to Foo, which (depending on
how liberally you want to interpret the standard) might give this function
call defined behavior -- in any case, the problem is not the vptr in that
case, so the vptr sanitizer should not complain. Alternatively the lifetime
of 'bar' might have ended, or (if Bar had a non-trivial default
constructor) the lifetime might not have started yet. In those cases, the
vptr sanitizer should complain. So I think we're right to insert a dynamic
check here.

When sanitizing for undefined behavior, you can't assume that undefined
behavior hasn't happened in order to optimize out checks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150416/60385626/attachment.html>


More information about the cfe-commits mailing list