This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

> From: Ian Lance Taylor <>
> Date: 04 Mar 2004 17:46:47 -0500

> Geoff Keating <> 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,

Um, I thought that was the point of this feature: it makes the kernel
map certain things at random locations.

> 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?

I know that host-darwin.c imposes no measurable overhead on gcc's load
time or its performance when PCH is not used, but I had to talk to
several kernel and linker people before settling on that particular
design (and even then I measured the resulting performance before I
really believed that it would work).  I think you will need to do the
same amount of research before you can come up with something similar
for linux.

> 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.

It's not particularly hard, it's just expensive in time and VM.
Since saving time is the point of PCH, that makes it not very

[This question is also a FAQ.  You are at least the fourth person to
ask it.  My usual response is "so, why can't you arrange for the PCH
to load at the location it was made for?"  Eventually, with enough
prodding, it has always turned out that indeed they can arrange this.
There may be hosts for which it's impossible, but Linux isn't one of them.]

- Geoffrey Keating <>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]