To quote gcc/aclocal.m4: /* 3. If we map two adjacent 1-page regions and unmap them both with one munmap, both must go away. Getting two adjacent 1-page regions with two mmap calls is slightly tricky. All OS's tested skip over already-allocated blocks; therefore we have been careful to unmap all allocated regions in previous tests. HP/UX allocates pages backward in memory. No OS has yet been observed to be so perverse as to leave unmapped space between consecutive calls to mmap. */ Well, UnixWare 7.1.1 is that perverse system. It seems to leave one page between each mapping. Release: 3.0 20010611 (prerelease) Environment: System: UnixWare oceanic 5 7.1.1 i386 x86at SCO UNIX_SVR5 host: i586-sco-sysv5uw7.1.1 build: i586-sco-sysv5uw7.1.1 target: i586-sco-sysv5uw7.1.1 configured with: ../gcc-3.0-20010611/configure --prefix=/u/local --with-local_prefix=/u/local How-To-Repeat: configure
From: Robert Lipe <robertlipe@usa.net> To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, john@Calva.COM, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org Cc: Subject: Re: bootstrap/3163 Date: Wed, 13 Jun 2001 11:45:25 -0500 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3163&database=gcc HP/UX allocates pages backward in memory. No OS has yet been observed to be so perverse as to leave unmapped space between consecutive calls to mmap. */ Well, UnixWare 7.1.1 is that perverse system. It seems to leave one page between each mapping. This is actually documented behaviour. From the mmap man page: References to pages in a mapped region which are beyond the page containing the end of a file will result in the delivery of a SIGBUS signal. It sounds like this test is looking for several undocumented characteristics of mmap that just happen to be true on some systems and not a general case mmap. Since the code provides a reasonable fallback, does this cause an actual problem or is it an observation that this test is failing becuase the OS doesn't satisfy the characteristics wanted by this test?
From: "Zack Weinberg" <zackw@stanford.edu> To: Robert Lipe <robertlipe@usa.net> Cc: gcc-gnats@gcc.gnu.org, john@Calva.COM Subject: Re: bootstrap/3163 Date: Wed, 13 Jun 2001 20:33:38 -0700 On Wed, Jun 13, 2001 at 11:45:25AM -0500, Robert Lipe wrote: > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3163&database=gcc > > HP/UX allocates pages backward in memory. No OS has yet > been > observed > to be so perverse as to leave unmapped space between > consecutive calls > to mmap. */ > > Well, UnixWare 7.1.1 is that perverse system. It seems to > leave > one page between each mapping. > > This is actually documented behaviour. From the mmap man page: > > References to pages in a mapped region which are beyond the > page containing the end of a file will result in the delivery of a > SIGBUS signal. That sentence is in everybody's mmap(2), but not everybody's mmap leaves one page between each successive anonymous mapping. The test is, however, too picky. I originally wrote it to exercise every last detail of a Cygwin runtime bug. I've seen problem reports go by for it on Solaris 8 and the Hurd as well as UnixWare 7.1.1. Fixing it just hasn't been very high on my list. It would probably be better to check for the buggy versions of Cygwin instead. I don't know how to do that reliably, or which version is the earliest in which the bug was fixed. See thread at http://gcc.gnu.org/ml/gcc-bugs/2000-11/msg00588.html. -- zw I now propose to do a little a priorizing of my own. -- Jerry Fodor, _The Mind Doesn't Work That Way_
From: "John Hughes" <john@Calva.COM> To: "Robert Lipe" <robertlipe@usa.net>, <gcc-gnats@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <nobody@gcc.gnu.org> Cc: Subject: RE: bootstrap/3163 Date: Thu, 14 Jun 2001 09:28:32 +0200 >> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3163&database=gcc >> No OS has yet been observed to be so perverse as to leave unmapped >> space between consecutive calls to mmap. */ >> >> Well, UnixWare 7.1.1 is that perverse system. It seems to leave >> one page between each mapping. > This is actually documented behaviour. From the mmap man page: > > References to pages in a mapped region which are beyond the > page containing the end of a file will result in the delivery of a > SIGBUS signal. No, that paragraph says that if I mmap 10 pages from a 5 page file access to the 5 pages beyond eof get a SIGBUS (note: not SIGSEGV). It says nothing about memory OUTSIDE the mmaped region.
From: Craig Rodrigues <rodrigc@attbi.com> To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, john@Calva.COM, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org Cc: Subject: Re: bootstrap/3163: gcc/aclocal.m4 mmap test fails on UnixWare 7.1.1 Date: Sat, 23 Feb 2002 21:56:20 -0500 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3163 john@calva.com posted this info in PR 3162: libiberty/aclocal.m4 has a check to see if strncmp runs off the end of the string. It incorrectly fails on systems where MAP_ANON(YMOUS) must be used without an open fd, for example UnixWare 7.1.1. --- libiberty/aclocal.m4.orig Wed Nov 22 09:32:26 2000 +++ libiberty/aclocal.m4 Wed Jun 13 12:48:35 2001 @@ -21,8 +21,6 @@ #ifndef MAP_ANON #ifdef MAP_ANONYMOUS #define MAP_ANON MAP_ANONYMOUS -#else -#define MAP_ANON MAP_FILE #endif #endif @@ -39,6 +37,10 @@ { #if defined(HAVE_MMAP) || defined(HAVE_MMAP_ANYWHERE) char *p; +#ifdef MAP_ANON + p = (char *) mmap (0, MAP_LEN, PROT_READ|PROT_WRITE, + MAP_ANON|MAP_PRIVATE, -1, 0); +#else int dev_zero; dev_zero = open ("/dev/zero", O_RDONLY); @@ -46,7 +48,8 @@ exit (1); p = (char *) mmap (0, MAP_LEN, PROT_READ|PROT_WRITE, - MAP_ANON|MAP_PRIVATE, dev_zero, 0); + MAP_FILE|MAP_PRIVATE, dev_zero, 0); +#endif if (p == (char *)-1) exit (2); else
From: Dara Hazeghi <dhazeghi@yahoo.com> To: gcc-gnats@gcc.gnu.org, john@Calva.COM Cc: Subject: Re: bootstrap/3163: gcc/aclocal.m4 mmap test fails on UnixWare 7.1.1 Date: Fri, 9 May 2003 01:19:29 -0700 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- trail&database=gcc&pr=3163 Hello, there have been no updates about this bug for over a year. Is this bug reported still an issue on this platform with current releases of gcc? Thanks, Dara
State-Changed-From-To: open->feedback State-Changed-Why: See Dara's question
I cannot say for sure whether or not this problem is still observable under UnixWare 7.1.1 but we have several other reports of similar problems (bug 8365, bug 10284) so I think it's still a concern.
*** Bug 8365 has been marked as a duplicate of this bug. ***
*** Bug 10284 has been marked as a duplicate of this bug. ***
I have checked in a patch for this bug in mainline: PR bootstrap/3163 * aclocal.m4 (AC_FUNC_MMAP_ANYWHERE, AC_FUNC_MMAP_FILE): Delete. (gcc_AC_FUNC_MMAP_BLACKLIST): New. * configure.in: Check for sys/mman.h and mmap in AC_CHECK_HEADERS and AC_CHECK_FUNCS lists, respectively. Use gcc_AC_FUNC_MMAP_BLACKLIST, not AC_FUNC_MMAP_ANYWHERE nor AC_FUNC_MMAP_FILE. * configure, config.in: Regenerate. It may be worthwhile to check this onto the 3.3 release branch as well but I'm not sure; in any case a bit more testing first is probably a good idea.
I got: test 3 nonconsecutive pages - 2000000000044000, 20000000002b8000 on ia64 Linux kernel from Red Hat and checking for working mmap from /dev/zero... no checking for working mmap with MAP_ANON(YMOUS)... no As the result, I had /* #undef HAVE_MMAP_DEV_ZERO */ /* #undef HAVE_MMAP_ANON */ #define HAVE_MMAP_FILE 1 in auto-host.h. Then I got bootstrap comparison failure. Could someone please move this patch to 3.3 branch?
patch checked into 3.3 branch, audit trail should catch up eventually.
Subject: Backport to 3.3 This was nice and easy to backport to 3.3 -- the only substantive change was use of fatal_io_error instead of internal_error with %m. zw
Created attachment 4285 [details] 3163-3.3.diff
Subject: Bug 3163 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_3-branch Changes by: zack@gcc.gnu.org 2003-06-25 23:14:58 Modified files: gcc : ChangeLog aclocal.m4 config.in configure configure.in ggc-page.c Log message: PR bootstrap/3163 * aclocal.m4 (AC_FUNC_MMAP_ANYWHERE, AC_FUNC_MMAP_FILE): Delete. (gcc_AC_FUNC_MMAP_BLACKLIST): New. * configure.in: Check for sys/mman.h and mmap in AC_CHECK_HEADERS and AC_CHECK_FUNCS lists, respectively. Use gcc_AC_FUNC_MMAP_BLACKLIST, not AC_FUNC_MMAP_ANYWHERE nor AC_FUNC_MMAP_FILE. * configure, config.in: Regenerate. * ggc-page.c (init_gcc): Call fatal_io_error, not abort, if opening /dev/zero fails. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.619&r2=1.16114.2.620 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/aclocal.m4.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.61.2.1&r2=1.61.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config.in.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.146.2.3&r2=1.146.2.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/configure.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.641.2.13&r2=1.641.2.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/configure.in.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.627.2.12&r2=1.627.2.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ggc-page.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.57.2.3&r2=1.57.2.4