https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Reid Kleckner from comment #5)
> (In reply to Maxim Ostapenko from comment #4)
> > This happens because in LLVM case ASan changes symbols size ('f' in our
> > case) and just breaks ABI for the library. Relinking binary each time we
> > replace non-sanitized library with sanitized one is undesirable for large
> > package oriented systems (e.g. distributives), so we need a general solution
> > for the problem.
>
> Can you elaborate as to why changing the size of a visible global in a
> shared lib is an ABI break with ELF? That's surprising to me, and my
> searches haven't helped me understand.
Because symbol size is part of the ABI, and LLVM emits different symbol size
between -fsanitize=address and -fno-sanitize=address.
E.g. COPY relocations use the st_size field, so you can have:
1) shared library originally not ASAN instrumented, binary (e.g. non-ASAN)
linked against it, then the shared library recompiled with ASAN - the size of
the symbol in the binary will be the one without padding, but LLVM incorrectly
registers the variable using global symbol rather than local alias and thus
assumes there is padding which is not available (plus you can get a runtime
warning on the st_size mismatch from the dynamic linker)
2) even without COPY relocations, you could have the same variable defined in
multiple shared libraries, if some of them are -fsanitize=address and the
others are not, there is mismatch between the variable sizes, and depending on
which library comes earlier in the symbol search scope, you could have either
the version without or with padding used at runtime, but the sanitized
libraries could very well register the non-padded one, making it fatal error to
access e.g. variables after it
