[PATCH,Take 3] Fix make closures.c use dlmmap,dlmunmap on cygwin.

[PATCH,Take 3] Fix make closures.c use dlmmap,dlmunmap on cygwin.

[Dave Korn]

[-- Attachment #1: Type: text/plain, Size: 2260 bytes --]

[ refs: http://gcc.gnu.org/ml/gcc-patches/2009-06/threads.html#02228
        http://gcc.gnu.org/ml/gcc-patches/2009-07/threads.html#00352 ]


    Hi again,

  This time I let it complete bootstrap before posting and ran the testsuite too.

>                 === libffi tests ===
> 
> 
> Running target unix
> FAIL: libffi.call/cls_1_1byte.c output pattern test, is 12 178: 190
> FAIL: libffi.call/cls_2byte.c output pattern test, is 12 127 1 13: 13 140
> FAIL: libffi.call/cls_align_pointer.c (test for excess errors)
> FAIL: libffi.call/return_sc.c execution test
> FAIL: libffi.call/struct5.c execution test
> FAIL: libffi.call/cls_1_1byte.c output pattern test, is 12 178: 190
> FAIL: libffi.call/cls_2byte.c output pattern test, is 12 127 1 13: 13 140
> FAIL: libffi.call/return_sc.c execution test
> FAIL: libffi.call/struct5.c execution test
> FAIL: libffi.call/cls_1_1byte.c output pattern test, is 12 178: 190
> FAIL: libffi.call/cls_2byte.c output pattern test, is 12 127 1 13: 13 140
> FAIL: libffi.call/return_sc.c execution test
> FAIL: libffi.call/struct5.c execution test
> FAIL: libffi.call/cls_1_1byte.c output pattern test, is 12 178: 190
> FAIL: libffi.call/cls_2byte.c output pattern test, is 12 127 1 13: 13 140
> FAIL: libffi.call/struct5.c execution test
> FAIL: libffi.call/cls_1_1byte.c output pattern test, is 12 178: 190
> FAIL: libffi.call/cls_2byte.c output pattern test, is 12 127 1 13: 13 140
> FAIL: libffi.call/return_sc.c execution test
> FAIL: libffi.call/struct5.c execution test
> 
>                 === libffi Summary ===
> 
> # of expected passes            1609
> # of unexpected failures        20
> # of expected failures          10

  These are comparable to the last recorded results on the
-testresults list:

  http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg00433.html

although there appears to be one regression:

+FAIL: libffi.call/cls_align_pointer.c (test for excess errors)

which is an unrelated format string warning.  The remaining new failures are
in new tests.  At least it builds again now and works comparably to how it
used to.

libffi/ChangeLog:

	* src/closures.c (is_selinux_enabled):  Define to 0 for cygwin.
	(dlmmap, dlmunmap):  Use POSIX versions on cygwin.

  Ok?

    cheers,
      DaveK


[-- Attachment #2: libffi-cygwin-mmap-fix-take-3.diff --]
[-- Type: text/x-c, Size: 1761 bytes --]

Index: libffi/src/closures.c
===================================================================
--- libffi/src/closures.c	(revision 149338)
+++ libffi/src/closures.c	(working copy)
@@ -165,7 +165,13 @@
 
 #define is_selinux_enabled() 0
 
-#endif
+#endif /* !FFI_MMAP_EXEC_SELINUX */
+
+#elif defined (__CYGWIN__)
+
+/* Cygwin is Linux-like, but not quite that Linux-like.  */
+#define is_selinux_enabled() 0
+
 #endif /* !defined(X86_WIN32) && !defined(X86_WIN64) */
 
 /* Declare all functions defined in dlmalloc.c as static.  */
@@ -185,11 +191,11 @@
 static size_t dlmalloc_usable_size(void*) MAYBE_UNUSED;
 static void dlmalloc_stats(void) MAYBE_UNUSED;
 
-#if !defined(X86_WIN32) && !defined(X86_WIN64)
+#if !(defined(X86_WIN32) || defined(X86_WIN64)) || defined (__CYGWIN__)
 /* Use these for mmap and munmap within dlmalloc.c.  */
 static void *dlmmap(void *, size_t, int, int, int, off_t);
 static int dlmunmap(void *, size_t);
-#endif /* !defined(X86_WIN32) && !defined(X86_WIN64) */
+#endif /* !(defined(X86_WIN32) || defined(X86_WIN64)) || defined (__CYGWIN__) */
 
 #define mmap dlmmap
 #define munmap dlmunmap
@@ -199,7 +205,7 @@
 #undef mmap
 #undef munmap
 
-#if !defined(X86_WIN32) && !defined(X86_WIN64)
+#if !(defined(X86_WIN32) || defined(X86_WIN64)) || defined (__CYGWIN__)
 
 /* A mutex used to synchronize access to *exec* variables in this file.  */
 static pthread_mutex_t open_temp_exec_file_mutex = PTHREAD_MUTEX_INITIALIZER;
@@ -514,7 +520,7 @@
 }
 #endif
 
-#endif /* !defined(X86_WIN32) && !defined(X86_WIN64) */
+#endif /* !(defined(X86_WIN32) || defined(X86_WIN64)) || defined (__CYGWIN__) */
 
 /* Allocate a chunk of memory with the given size.  Returns a pointer
    to the writable address, and sets *CODE to the executable

Re: [PATCH,Take 3] Fix make closures.c use dlmmap,dlmunmap on cygwin.

[Dave Korn]

Dave Korn wrote:
> [ refs: http://gcc.gnu.org/ml/gcc-patches/2009-06/threads.html#02228
>         http://gcc.gnu.org/ml/gcc-patches/2009-07/threads.html#00352 ]

  Interestingly, the problem doesn't reproduce directly on upstream libffi.
There must be something different in the #ifdeffery, because what happens
instead is that dlmalloc doesn't select its own win32 mmap/munmap
replacements, but instead calls dlmmap and dlmunmap directly.  These are
apparently defined in a cygwin header file somewhere, but not actually
implemented or exported, so all the tests fail to link with undefined symbol
errors referring to dlmmap/dlmunmap.

  With the patch applied, libffi uses its reimplementations of those functions
and relies on the underlying c library support for mmap/munmap, which works.
The test results are quite different, though:

> 		=== libffi Summary ===
> 
> # of expected passes		1563
> # of unexpected failures	66
> # of expected failures	10

  And I know everything is not quite right because these warnings appear
during the build, which made me look back and notice that they appeared in my
gcc build as well:

/gnu/libffi/libffi/src/closures.c: In function 'dlmmap_locked':
/gnu/libffi/libffi/src/closures.c:405:3: warning: implicit declaration of
function 'mmap'
/gnu/libffi/libffi/src/closures.c:405:7: warning: assignment makes pointer
from integer without a cast
/gnu/libffi/libffi/src/closures.c:421:9: warning: assignment makes pointer
from integer without a cast
/gnu/libffi/libffi/src/closures.c:425:7: warning: implicit declaration of
function 'munmap'
/gnu/libffi/libffi/src/closures.c: In function 'dlmmap':
/gnu/libffi/libffi/src/closures.c:456:11: warning: assignment makes pointer
from integer without a cast


  Bah.  I think I should withdraw the patch while I try and figure out why
it's not picking up the declarations of those functions, and why the two
behave so differently.

    cheers,
      DaveK