On Thu, Apr 14, 2011 at 12:09 PM, Richard Sandiford <richard.sandif...@linaro.org> wrote: > Dave Martin <dave.mar...@linaro.org> writes: >> 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...) > > 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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
