https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #16 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #15)
> (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.
Frankly, I realize that I don't understand the subtleties of this problem. :(
First, if this is C++ we clearly have a bug (ODR violation) and we are done.
Then, if this is C w/o any extra flags we will not instrument these globals.
Done.
Finally, if this is C with -fno-common, I am not sure if the C standard covers
this and how we should behave.
