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 4:48 PM, Jakub Jelinek <jakub@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