On Wed, Apr 13, 2011 at 11:11 PM, Michael Hope <michael.h...@linaro.org> wrote: > Hi there. The address space randomisation feature in 2.6.35 and above > kernels breaks GCC's precompiled headers support. GCC works by > compiling the header once, dumping the internal format out to disk, > and then mmap()ing it back in at a fixed address. The solution for > other architectures is for GCC to pick a spot in the virtual address > space that is likely to be free and map the PCH in there. Most of > them use 0x60000000 which from a bit of poking seems to be fine on ARM > as well.
This does sound rather an alarming design ... would it be hard to make the PCH blobs relocatable or position-independent? How does GCC cope with multiple precompiled headers? Making them relocatable or position-independent might allow many to be mapped simultaneously, which might actually be a performance win (based on zero knowledge of the nature of this data or what GCC does with it...) Cheers ---Dave > > Can someone point me at the typical virtual address space for a ARM > Linux process? How does 0x60000000 sound? > > For reference, this is the code in kernel/arch/arm/mm/mmap.c that > exposes the problem: > /* 8 bits of randomness in 20 address space bits */ > if (current->flags & PF_RANDOMIZE) > addr += (get_random_int() % (1 << 8)) << PAGE_SHIFT; > > The GCC code with addresses for other architectures lives at: > http://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.5/view/head:/gcc/config/host-linux.c#L67 > > /proc/self/maps on a simple program gives: > > 00008000-00009000 r-xp 00000000 00:14 28747240 /home/michaelh/a.out > 00010000-00011000 r--p 00000000 00:14 28747240 /home/michaelh/a.out > 00011000-00012000 rw-p 00001000 00:14 28747240 /home/michaelh/a.out > 00012000-00033000 rw-p 00000000 00:00 0 [heap] > 2ab4c000-2ab4d000 rw-p 00000000 00:00 0 > 2ab5c000-2ab5e000 rw-p 00000000 00:00 0 > 2ab89000-2aba0000 r-xp 00000000 00:0d 26352847 /lib/ld-2.12.1.so > 2aba8000-2aba9000 r--p 00017000 00:0d 26352847 /lib/ld-2.12.1.so > 2aba9000-2abaa000 rw-p 00018000 00:0d 26352847 /lib/ld-2.12.1.so > 2ac35000-2ac36000 rw-p 00000000 00:00 0 > 2ac93000-2aca0000 r-xp 00000000 00:0d 26352795 /lib/libbz2.so.1.0.4 > 2aca0000-2aca7000 ---p 0000d000 00:0d 26352795 /lib/libbz2.so.1.0.4 > 2aca7000-2aca8000 r--p 0000c000 00:0d 26352795 /lib/libbz2.so.1.0.4 > 2aca8000-2aca9000 rw-p 0000d000 00:0d 26352795 /lib/libbz2.so.1.0.4 > 2aca9000-2ad96000 r-xp 00000000 00:0d 26352832 /lib/libc-2.12.1.so > 2ad96000-2ad9e000 ---p 000ed000 00:0d 26352832 /lib/libc-2.12.1.so > 2ad9e000-2ada0000 r--p 000ed000 00:0d 26352832 /lib/libc-2.12.1.so > 2ada0000-2ada1000 rw-p 000ef000 00:0d 26352832 /lib/libc-2.12.1.so > 2ada1000-2ada4000 rw-p 00000000 00:00 0 > 7ed9c000-7edbd000 rw-p 00000000 00:00 0 [stack] > > 0x60000000 is well above the shared libraries and well below the stack. > > -- Michael > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
