[Bug sanitizer/80027] ASAN breaks DT_RPATH $ORIGIN in dlopen()

[m.ostapenko at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80027

--- Comment #4 from Maxim Ostapenko <m.ostapenko at samsung dot com> ---
(In reply to Michael Thayer from comment #3)
> Seems my mistake.  I think the ASAN library was still getting loaded
> dynamically.  Now I have the following problem, which I think means that
> code (constructors?) getting called before ASAN is initialised is getting
> hold of memory map areas which ASAN is hard-coded to use.  So probably no
> static ASAN for me.
> 
> ==10420==Shadow memory range interleaves with an existing memory mapping.
> ASan cannot proceed correctly. ABORTING.
> ==10420==ASan shadow was supposed to be located in the
> [0x00007fff7000-0x10007fff7fff] range.
> ==10420==Process memory map follows:
> 	0x00007fff7000-0x00008fff7000	
> 	0x00008fff7000-0x02008fff7000	
> 	0x02008fff7000-0x10007fff8000	
> [...]

This usually happens when your executable isn't linked with libasan but some
shared library is. Check that your test binary is properly linked with libasan.