|
View:
New views
2 Messages
—
Rating Filter:
Alert me
|
|
|
[PATCH,Take 3] Fix make closures.c use dlmmap,dlmunmap on cygwin.[ 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 -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 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 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 |
| Free embeddable forum powered by Nabble | Forum Help |