On Wed, Apr 13, 2011 at 11:11 PM, Michael Hope michael.hope@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:/...
/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