[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable

a.drobyshev at samsung dot com gcc-bugzilla@gcc.gnu.org
Mon Mar 18 13:53:00 GMT 2019


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?


More information about the Gcc-bugs mailing list