This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: PATCH: Fix 64-bit libffi testsuite on Solaris 10+ (PR libffi/40700)
- From: Andrew Haley <aph at redhat dot com>
- To: Andreas Tobler <andreast-list at fgznet dot ch>
- Cc: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>, gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org, libffi-discuss at sourceware dot org
- Date: Fri, 11 Dec 2009 09:43:20 +0000
- Subject: Re: PATCH: Fix 64-bit libffi testsuite on Solaris 10+ (PR libffi/40700)
- References: <yddpr6nhacf.fsf@manam.CeBiTec.Uni-Bielefeld.DE> <4B20C4D4.3000605@redhat.com> <4B2170EE.5020203@fgznet.ch>
Andreas Tobler wrote:
> On 10.12.09 10:52, Andrew Haley wrote:
>> Rainer Orth wrote:
>>> As described in the PR, many 64-bit libffi testcases started to fail on
>>> Solaris 10 and 11 between 20090612 and 20090622. Core dump logging
>>> revealed the cause:
>>>
>>> Nov 27 14:45:24 cumaru genunix: [ID 269049 kern.notice] NOTICE: cls_ushort.exe[21514] attempt to execute non-executable data at 0x600fd0 by uid 2110
>>>
>>> I could track this to the following patch:
>>>
>>> 2009-06-11 Timothy Wall<twall@users.sf.net>
>>> [...]
>>> * testsuite/libffi.call/closure_fn0.c,
>>> [...]
>>> testsuite/libffi.special/unwindtest.cc: use ffi_closure_alloc instead
>>> of checking for MMAP. Use intptr_t instead of long casts.
>>>
>>> While before the patch, the testsuite would have used allocate_mmap to
>>> allocate ffi_closure's, afterwards src/closures.c (ffi_closure_alloc)
>>> without FFI_MMAP_EXEC_WRIT defined would simply use malloc instead,
>>> leading to the observed failure.
>>>
>>> So the fix is obvious: just define FFI_MMAP_EXEC_WRIT for 64-bit
>>> Solaris/x86. The following patch does just that and allows the libffi
>>> testsuite to complete almost successfully (the remaining failures are
>>> unrelated) for both 32 and 64 bit on i386-pc-solaris2.11.
>>>
>>> Ok for mainline?
>> Yes, thanks.
>>
>> Cc'd to libffi upstream.
>
> I'm late.
>
> Anyway, there are other architectures which do have the same issue.
> FreeBSD, OpenBSD, apple-darwin10. We 'solved' this with adding the
> snippet below in the configure.ac (from the libffi sources, not in the
> gcc repo yet.):
>
> case "$target" in
> *-apple-darwin10* | *-*-freebsd* | *-*-openbsd*)
> AC_DEFINE(FFI_MMAP_EXEC_WRIT, 1,
> [Cannot use malloc on this target, so, we revert to
> alternative means])
> ;;
>
>
> So, my question, shall we move the three remaining OS variants into the
> closures.c file. Or should we move the solaris/x86 part from the
> closures.c file into the configure.ac part?
>
> Both are ok with me, but I think we should have a consistency in this area.
Please do whatever you find the most elegant and consistent: I'm sure we will
trust you to find the sweet spot...
Andrew.