On Wed, Feb 13, 2013 at 5:07 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Wed, Feb 13, 2013 at 04:57:30PM +0400, Konstantin Serebryany wrote: >> On Wed, Feb 13, 2013 at 4:48 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> > On Wed, Feb 13, 2013 at 04:32:33PM +0400, Konstantin Serebryany wrote: >> >> > Unfortunately, it seems everything fails with that change :( on Linux. >> >> > The problem is that the default prelink library range for x86_64 is >> >> > 0x3000000000LL to 0x4000000000LL, and that unfortunately overlaps >> >> >> >> Forgive my ignorance, what is the default prelink library range? >> > >> > Prelink is a program of mine (see e.g. >> > http://people.redhat.com/jakub/prelink.pdf >> > ) that speeds up dynamic linking of programs. >> > It is used by default on various Linux distributions. >> >> Can it be disabled somehow (for asan)? > > No. You can disable it for the whole system (prelink -ua), but that is not > a sane requirement to running sanitized programs.
Why not? :) >> There is > also LD_USE_LOAD_BIAS=0 env variable, but 1) that has to be set before > running the program, setting it from within libasan ctor is too late, This we can deal with. We already setenv+reexec on Mac to solve similar issue with Mac's dynamic run-time. > and > more importantly 2) it still doesn't affect the mapping of the dynamic > linker. So, with LD_USE_LOAD_BIAS=0 cat /proc/self/maps the > dynamic linker will be still mapped somewhere in the 0x3000000000 to > 0x4000000000 range, just other shared libraries mapped in by the dynamic > linker, rather than kernel directly, will be placed at the randomized (and > usually high) addresses, typically 0x7fXXXXXXXXXX. > >> If we enabled flexible mapping in the gcc build (making it more >> similar to the llvm build) >> we will be able to use the old 2^44 offset w/o changing the asan-rt. > > Sure, but it will be then slower, I thought you are looking for ASAN speed > improvements. Yes, and we already achieved it on ubuntu :) > >> That's yet another set of spaghetti ifdefs. >> I'd rather revert the whole thing back to 2^44 than do that. > > Please revert the two hunks now. That's a bummer. We've already deployed Clang with the new setting and will likely not want to revert it there. If we revert the two hunks in gcc (in gcc/config/i386/i386.c and in asan_mapping.h) we will have larger inconsistency between gcc and clang variants. But if we switch to flexible mapping in gcc (will require gcc to emit the two globals) we will only need to revert gcc/config/i386/i386.c and the run-times in clang and gcc will remain the same. > I'll try to implement it eventually and > try to convince you ;) That's surely not hard to implement, but very hard to support. --kcc > > Jakub
