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

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

Richard Henderson <rth@redhat.com> writes:

> On Thu, Mar 04, 2004 at 12:59:38PM -0800, Geoff Keating wrote:
> > 2. If mincore() doesn't work, it shouldn't be used.  GGC is not the
> >    only source of anonymous mapped pages, libc can create them too
> >    (via malloc, for instance).
> 
> While I agree that mincore should work, one *can* get proper vma
> information from /proc/self/maps.  It should be easy enough to
> have ggc-foo actively release all memory, then check the maps.

As I think about this more, I see that I did misunderstand the issue.

My current understanding is that the calls to mincore() are there
because the Solaris mmap() will sometimes not return the desired
address even when that would work as a mapping address.  In that case,
the code will check mincore to see whether the desired address should
work and, if so, force it by using MAP_FIXED.

On Linux, mincore() is evidently buggy, at least in 2.4.22.  On the
other hand, mmap() works as expected.  The effect is that if the
desired mapping is not available, mincore() will indicate that it is
available, and the code will then use MAP_FIXED to force it.  This
will fail later as the same memory addresses are used for two
different purposes.

So: on Solaris, if the initial mmap() fails, we want to double-check
and possibly force it.  On Linux, we should trust the initial mmap()
result.

I was seeing bad results (compiler crashes) because of the buggy
mincore() on Linux.  If mincore() worked correctly, I would have seen
an error message rather than a crash.  If gcc trusted Linux to handle
mmap() as expected, it would not have checked mincore(), and I would
have seen an error message rather than a crash.

So: could somebody with access to a Solaris system please compile and
run the appended little program, and please tell me the exit status?
I am hoping that the exit status will be 0.  On Linux, the exit status
is 1.  The most relevant Solaris system would be Solaris 9, since that
is what PR 9830 was reported against.

If that works, then we don't need to worry about /proc/self/maps.  We
can just assume that if mmap() fails, the address is not available.

> As for choosing a good place to allocate in the first place...
> 
> It ought to be trivial for the 64-bit targets to just hard-code
> a host-specific value, e.g. 0x10000000000 for Alpha.
> 
> For x86, however, the memory map changes enough that I don't
> know that there is an algorithm that *always* works.  I might
> guess that Ian's "allocate a large block" approach is as good
> as any.

Richard, do you have any insight into how expensive it would be to
massively increase the BSS size of the cc1 process?  That is
effectively what host-darwin.c does.  host-darwin.c goes ahead and
calls munmap on space which it doesn't need, but it only does that in
the special case of actually reading a PCH file, not in the normal
case of no PCH file.

Ian

The program to test on Solaris:

==================================================
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/mman.h>

#ifndef MAP_FAILED
#define MAP_FAILED ((void *) -1)
#endif

int
main ()
{
#ifndef MAP_ANONYMOUS
  exit (0);
#else
  size_t pagesize = getpagesize ();
  void *p = mmap (0, pagesize, PROT_READ | PROT_WRITE,
		  MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
  char c;
  if (p == MAP_FAILED)
    exit (0);
  errno = 0;
  exit (mincore (p, pagesize, &c) == -1 && errno == ENOMEM);
#endif
}
==================================================