https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
--- Comment #30 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Andrey Drobyshev from comment #26) > > I would like to ask, has the idea of adding an artificial object linked with > > -fsanitize=address early on the link line which would register artificial > > dummy variables in at least the most common data sections been considered > > and rejected? > > I mean, it should at least for large libraries mean significantly fewer > > dummy variables, on the other side, when mixing sanitized and non-sanitized > > objects within one binary/library (having sanitized ones first and then say > > linking a static library non-sanitized would be fine) would mean catching up > > fewer issues. > > Could you describe how you imagine this solution in more details? Wouldn't > it require us to patch the linker along with compiler? Exactly like we are doing it already in other cases, look at libgcc/crtstuff.c which e.g. adds (or depending on configuration used to add) snippets of various sections early when compiled as crtbegin.o or crtbeginS.o etc. and snippets of various sections late when compiled as crtend.o etc. So, it would be a matter of adding another object like asan_preinit.o, that would contain registered empty globals in a couple of most common data sections, be compiled with -fpic and link it in in LIBASAN_EARLY_SPEC, unlike libasan_preinit regardless of -shared or not.
