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)? > prelinked shared > libraries (and dynamic linker) have their base addresses chosen by the > prelink program (and, by default in the default range of shared libraries > for the architecture, which is 0x3000000000LL to 0x4000000000LL for x86_64). > The addresses are usually (depending on prelink options) randomized upon > prelinking, so different hosts use different addresses and the same host > even after a while uses different addresses too, but by default for a few > weeks, if say glibc isn't upgraded in between, you get the same addresses > for the libraries all the time. > So, you get something like: > cat /proc/self/maps > 00400000-0040b000 r-xp 00000000 08:02 1201920 > /usr/bin/cat > 0060a000-0060b000 r--p 0000a000 08:02 1201920 > /usr/bin/cat > 0060b000-0060c000 rw-p 0000b000 08:02 1201920 > /usr/bin/cat > 01431000-01452000 rw-p 00000000 00:00 0 > [heap] > 3fe9400000-3fe9420000 r-xp 00000000 08:02 1179965 > /usr/lib64/ld-2.15.so > 3fe961f000-3fe9620000 r--p 0001f000 08:02 1179965 > /usr/lib64/ld-2.15.so > 3fe9620000-3fe9621000 rw-p 00020000 08:02 1179965 > /usr/lib64/ld-2.15.so > 3fe9621000-3fe9622000 rw-p 00000000 00:00 0 > 3fe9800000-3fe99ac000 r-xp 00000000 08:02 1180697 > /usr/lib64/libc-2.15.so > 3fe99ac000-3fe9bac000 ---p 001ac000 08:02 1180697 > /usr/lib64/libc-2.15.so > 3fe9bac000-3fe9bb0000 r--p 001ac000 08:02 1180697 > /usr/lib64/libc-2.15.so > 3fe9bb0000-3fe9bb2000 rw-p 001b0000 08:02 1180697 > /usr/lib64/libc-2.15.so > 3fe9bb2000-3fe9bb7000 rw-p 00000000 00:00 0 > 7fae406f5000-7fae46b22000 r--p 00000000 08:02 1215605 > /usr/lib/locale/locale-archive > 7fae46b22000-7fae46b25000 rw-p 00000000 00:00 0 > 7fae46b42000-7fae46b43000 rw-p 00000000 00:00 0 > 7fffe04f7000-7fffe0518000 rw-p 00000000 00:00 0 > [stack] > 7fffe05e6000-7fffe05e7000 r-xp 00000000 00:00 0 > [vdso] > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 > [vsyscall] > > Perhaps Ubuntu doesn't enable prelink by default, but all the world isn't > Ubuntu. > >> I suggest to either revert or (better) to support flexible mapping and >> revert the offset only in the gcc compiler module >> (leaving asan-rt unchanged). > > I don't see how could flexible mapping help in this case, it just can't work > either. 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. > The only exception are PIE binaries, which by design aren't prelinked and > kernel > for them disregards the prelinking of the dynamic linker, so the dynamic > linker > for PIEs isn't loaded at the prelink chosen address, but at some randomized > address. > > If you try -Wl,-Ttext* with flexible mapping and use either zero base, or say > 0x7fff8000, > you run into the exactly same issues, wether with gcc or clang. > >> non-contiguous shadow memory sounds too scary and costly to support, >> not worth the benefit. > > Why do you think it should be too costly? That's yet another set of spaghetti ifdefs. I'd rather revert the whole thing back to 2^44 than do that. --kcc
