https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Martin Liška from comment #23) > (In reply to Andrey Drobyshev from comment #22) > > Created attachment 45851 [details] > > Work-in-progress fix considering relocations > > > > I'm a bit stuck. I managed to precompute reloc value for the globals (the > > code for detect_reloc_for_node() is stealed from get_variable_section ()). I > > also succeded in putting dummy variable into .data.rel.ro by making a decl > > of a pointer type. > > Nice progress! > > > But .data.rel is not working: checks from varasm.c:1173 > > and varasm.c:1197 are somewhat conflicting. Maybe you could find a way to > > overcome this? > > Can you please paste content of the lines, the lines you mentioned point to > a '}' for me. 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.
