https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #14 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
(In reply to Yury Gribov from comment #13)
> (In reply to Kostya Serebryany from comment #12)
> > But for this example in C the globals will not get instrumented, unless
> > -fno-common is given.
>
> BTW I think everyone already pairs this with -fsanitize=address, otherwise
> sanitization of globals becomes so weak.
Dunno. That's what we recommend.
>
> >> If LLVM uses global symbols instead of local aliases, it is more expensive.
> >> You can have aliases/weakrefs etc. to symbols, and those still aren't ODR
> >> violations.
> >
> > But these again should not be instrumented by asan at all. No?
>
> Wouldn't that cause false negatives for internal references to local aliases?
We should be careful when instrumenting something that can be redefined because
the
definition may be no-instrumented.
Consider a case where
a.c has a weakref (or whatever else that can be redefined) and
b.c had a regular definition.
Then, a.c is instrumented and b.c is not. Bad.
>
> > Never seen a case like this ("registered multiple times for multiple
> > addresses").
> > Can you give an example?
>
> How about this: say some global variable xyz is defined both in executable
> and in shared library. Now
> 1) if xyz isn't exported from executable, it will not be available to shlib;
> so exe's internal references will bind to exe's definition but shlib's
> references will bind to shlib's definition
> 2) if xyz is exported from executable but shlib is linked with -Bsymbolic,
> shlib's internal references will bind to shlib's implementation
> 3) RTLD_DEEPBIND could also alter symbol resolution order in a shlib
