This is the mail archive of the gcc-patches@gcc.gnu.org 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


Richard Henderson <rth@redhat.com> 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:
    http://www.dimi.uniud.it/cgi-bin/man-cgi?mincore+2
    ENOMEM
           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
> option.

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.

Ian


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