This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: libsanitizer merge from upstream r175042
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. 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.
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?
Jakub