<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 5, 2014 at 7:06 AM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Clang folks, <br><br>I have a question about typeinfo variables:<br><br>% cat a1.cc<br>struct AAA {<br>
 public:<br>  virtual ~ AAA ();<br>};<br>AAA::~AAA() { }<br>void foo () { throw AAA (); }<br><br>% clang++ a1.cc -S -o - -emit-llvm    | grep '_ZTI3AAA.=.[^{]*' -o <br>
_ZTI3AAA = constant <br><br>% clang++ a1.cc -S -o - -emit-llvm  -fno-rtti  | grep '_ZTI3AAA.=.[^{]*' -o <br>_ZTI3AAA = linkonce_odr constant <br><br>As you can see, depending on the compilation mode (-fno-rtti) the definition of _ZTI3AAA<br>

(typeinfo for AAA) is different.  Is that expected? <br></div></blockquote><div><br></div><div>Yes, I think so: if we have a key function, we can emit the type_info as a strong symbol with that key function, because we know there will only be one such translation unit in the program. (We could emit the _ZTI3AAA symbol as strong in both cases in the above program, but in the second case we're explicitly not required to provide a definition for other TUs, so we reduce the linkage to linkonce_odr).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This difference causes problem for AddressSanitizer, if one part of the code is built with <br>
-fno-rtti and another part w/o -fno-rtti. <br>asan instruments global constants but can not instrument linkonce_odr variables,<br>
as a result we mix an instrumented and a non-instrumented global in the same binary. <br></div></blockquote><div><br></div><div>Per the LangRef, it seems that it's permissible to have both a linkonce_odr definition and an external definition of the same entity in the same program, so this seems like an ASan issue. We could work around it by reducing the linkage to linkonce_odr in the -frtti case (the global will not be discarded because it's used by the vtable). That is apparently what GCC does. But ASan will presumably still have problems with this:</div>
<div><br></div><div>tu1.c:</div><div>__attribute__((weak)) int n = 1;</div><div><br></div><div>tu2.c:</div><div>int n = 2;</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><a href="https://code.google.com/p/address-sanitizer/issues/detail?id=327" target="_blank">https://code.google.com/p/address-sanitizer/issues/detail?id=327</a></div></blockquote><div><br></div><div>I don't fully understand the problem here. It seems that:</div>
<div>  1) weak linkage globals don't get instrumented</div><div>  2) instrumented globals get 8 byte alignment</div><div>  3) you're seeing a global with both a weak definition and a non-weak definition</div><div>
  4) the assert fails because you believe the variable is instrumented, but it doesn't have 8 byte alignment</div><div>If so, I wonder why you're seeing the weak definition rather than the strong, 8-byte-aligned instrumented definition that you should see?<br>
</div></div></div></div>