[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

["kcc at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.