This is the mail archive of the libffi-discuss@sourceware.org mailing list for the libffi project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Fix 64-bit libffi testsuite on Solaris 10+ (PR libffi/40700)


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]