rsmith added a comment.
This is causing ASan's ODR violation detector to fire. I think the problematic
case looks like this:
TU 1:
struct X;
/*...*/ typeid(X*); /*...*/
TU 2:
struct X { virtual void f(); };
void X::f() {}
Now, TU 1 will emit a `linkonce_odr` definition of the `_ZTS` symbol, and TU 2
will emit a strong definition of it. ASan doesn't like that.
There's no way we can know that there will be a strong definition of the
typeinfo name at the point where we emit the tentative copy for the pointer
`type_info`. It seems to me there are two things we could do about this:
1. decide this is not a bug and suppress the ASan ODR checker report, or
2. decide this is a bug, and only emit `linkonce_odr` typeinfo names for
pointers to incomplete classes, not for incomplete classes themselves (this
would mean that `operator==` etc would do the wrong thing for users who use the
<cxxabi.h> to inspect the pointee type of a pointer type info; in particular,
we'd need to check that ubsan's vptr sanitizer can cope with this -- right now
it assumes that it can compare the type name address except on iOS64, just like
libc++'s `<type_info>` does).
Repository:
rC Clang
https://reviews.llvm.org/D46665
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
