On Wed, Feb 13, 2013 at 2: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. 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, 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.
ASAN could set an ELF flag on the executable to tell the kernel not to use prelinked objects? That is, similar to how we handle executable stacks? Richard. >> 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. > >> 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. I'll try to implement it eventually and > try to convince you ;) > > Jakub
