https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Kostya Serebryany from comment #14)
> We should be careful when instrumenting something that can be redefined
> because the
> definition may be no-instrumented.
But that is a strong argument why what GCC does is desirable and not what LLVM
does.
Say you have:
int f = 4;
int g = 5;
int foo (int *p) { return *p; }
in libfoo.c and
int f = 4;
int g = 5;
int foo (int *);
int main ()
{
return foo (&f) - 4;
}
Suppose libfoo.c is compiled/linked with -fsanitize=address -fpic -shared.
Suppose main.c is compiled without -fsanitize=address.
GCC will use in registration of global symbols in libfoo.c the local alias to f
and g, so registers something that in the end is not used, because f in the
executable comes earlier in the search scope. But registers something that is
known to be properly padded for asan.
LLVM doesn't use a local alias, and so will happily register the f and g
symbols in the binary, but as if they had the padding which they most probably
don't. So you can end up with false positives or false negatives that way.
But when you use local aliases, obviously the current way of ODR checking can't
work and should use symbol names instead.
