Re: Give a better error for PCH with exec-shield-randomize

[Ian Lance Taylor <ian at wasabisystems dot com>]

Geoff Keating <geoffk@desire.geoffk.org> writes:

> > I don't have a good way to do some real testing without using the
> > testsuite, though.  It's pretty hard to be confident that this will
> > always do the right thing.
> 
> I'm pretty sure that this will sometimes go wrong, because it doesn't
> really prevent the kernel (or prelink) from randomly deciding to map
> something in the space that the PCH file wants.  It's a definite step
> in the right direction, though.

The kernel doesn't act randomly, of course, and it doesn't
deliberately randomize the placement of non-executable mmap calls, and
it tends to put executables on one side of the memory map and
non-executables on the other side.  I based this approach on what
Linux 2.4.22 does on the i386, and it ought to work there.  But I
don't know what other kernel versions do, nor what other processors
do.  (Nor do I know whether any other processors are likely to
implement exec-shield-randomize--in 2.4.22 only the i386 does.)

I could do something along the lines of what host-darwin.c does, or I
could futz with the linker map, or I could just grab space in a
host-specific initialization routine like the extra_signals() host
hook, but any of those approaches force every execution of cc1/cc1plus
to pay a price which need only be paid when PCH is used.  I'm not
really happy about that.  On the other hand, I also don't currently
have a clear understanding of the costs of mapping more pages.

Does anybody have any other thoughts?

Doesn't PCH have to swizzle pointers when it loads them into the
allocated memory region to save the PCH file?  What's so hard about
swizzling them when the PCH file is loaded?  I guess I should try to
understand more clearly what it is doing on the save side.

Ian