https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
--- Comment #26 from Andrey Drobyshev <a.drobyshev at samsung dot com> --- (In reply to Jakub Jelinek from comment #24) > (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. Could you describe how you imagine this solution in more details? Wouldn't it require us to patch the linker along with compiler?
