On Thu, Apr 14, 2011 at 12:09 PM, Richard Sandiford richard.sandiford@linaro.org wrote:
Dave Martin dave.martin@linaro.org writes:
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...)
The current PCH implementation is years old, and is really a hack that sits on top of the garbage collector. It basically dumps all of GCC's internal state out at a particular point, then reads it back in when the "precompiled header" is used. It's therefore only possible to have one precompiled header per compilation.
The model is that the package using PCH should have a common set of includes that every translation unit uses (or is at least prepared to accept). This common set can be put in the PCH, which must be included before anything else.
Like I said, a hack :-)
eeaarrgh
There is an ongoing project to use a streamed form of PCH. It's much more work than the current implementation was, but it should avoid the main drawbacks.
Oh well, I will await developments with interest... ;)
---Dave