This is the mail archive of the
mailing list for the GCC project.
Re: Give a better error for PCH with exec-shield-randomize
Richard Henderson <firstname.lastname@example.org> writes:
> On Thu, Mar 04, 2004 at 08:55:20PM -0500, Ian Lance Taylor wrote:
> > On Linux, mincore() is evidently buggy, at least in 2.4.22.
> Unfortunately, it's working as designed; man mincore sez
> ENOMEM address to address + length contained unmapped memory,
> or memory not part of a file.
> Note the last clause. I suppose there's bits in the BUGS section
> that acknowledge that you get ENOMEM for anonymous memory. I don't
> quite know what to make of that. Perhaps this worked with a 2.2
> kernel, and someone's vm redesign broke it. Who knows.
Hmmm. On Solaris, mincore does not have that clause:
Addresses in the range [addr, addr + len] are invalid
for the address space of a process or specify one or
more pages which are not mapped.
The function comes from 4.4BSD, and I don't have a copy of that. But
I suspect the ENOMEM clause in the Linux man page correctly describes
the Linux functionality, but is not compatible with BSD mincore
implementations. The Linux functionality also appears less useful to
me; it doesn't help much to learn that a reference to that page may or
may not succeed. But maybe buggy is not the right word.
> > Richard, do you have any insight into how expensive it would be to
> > massively increase the BSS size of the cc1 process?
> If memory overcommit protection is on, you'll have to really have
> that muct free virtual memory to even start up cc1. Similarly
> with your large allocation scheme. I can't see this as a viable
Note that the large allocation only happens when creating a PCH file,
not when reading one. I think the cost is more acceptable in that
case, though obviously still not ideal.