Commit f7879bc results in some 650 "test for excess errors" test failures. The CHECK() macro is throwing unused value warnings. If I revert that commit, all tests pass successfully.

In trying to maintain a libffi binding for the D programming language, we have to do really fragile attempts at mirroring configuration detection in libffi. This has turned out to fail several times (human parsing of C preprocessor forests can be rather hard!). Would it be feasible to add an ffi_get_trampoline_size() (or so) function that just returns FFI_TRAMPOLINE_SIZE?

The default gcc shipped with x64 Ubuntu (other distributions are affected likely as well)
only defines the following x64 related symbols processor symbols by itself:

#define __x86_64 1
#define __amd64 1
#define __x86_64 1
#define __x86_64__ 1

This leads to defining the trampoline size to 10 bytes as per
https://github.com/atgreen/libffi/blob/master/src/x86/ffitarget.h#L115
Due to neither X86_64 nor X86_DARWIN being defined.

Initializing the closure ion the x64 system writes beyond the allocated limit:
https://github.com/atgreen/libffi/blob/master/src/x86/ffi64.c#L520

This goes unnoticed by valgrind and did not manifest as bugs for us during normal application runtime.
However it gives catastrophic failures as soon one tries to free the initialized closure by signaling SIGABRT.

Current possible workarounds are

1.) overcommit during ffi_closure_alloc()
2.) manually define X86-64 as preprocessor symbol
3.) leak all closures and "pray"

Hello,

In documentation there is note about possibility to pass NULL as RVALUE in ffi_call(), this seems to not work on all platforms.

on AMD64/Linux running slighty modified puts programs on libffi-3.0.10rc8 gives me SIGSEGV:

#include <stdio.h>
#include <ffi.h>

int main()
{
        ffi_cif cif;
        ffi_type *args[1];
        void *values[1];
        char *s;

        /* Initialize the argument info vectors */
        args[0] = &ffi_type_pointer;
        values[0] = &s;

        s = "Hello World!";

        printf("before call\n");

        if (ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 1, &ffi_type_uint, args) == FFI_OK)
                ffi_call(&cif, puts, NULL, values);

        /* never here */
        printf("after call\n");

        return 0;
}

running in gdb:

.Lst_uint32:
0x00007ffff7bd8164 <+208>: mov %eax,%eax
=> 0x00007ffff7bd8166 <+210>: mov %rax,(%rdi)
0x00007ffff7bd8169 <+213>: nop

but looking on other implementation .S rvalue is sometimes checked for NULL

win32.S
76 ;; If the return value pointer is NULL, assume no return value.
77 cmp rvalue, 0
78 jne ca_jumptable

sysv.S
/* If the return value pointer is NULL, assume no return value. */
cmpl $0,24(%ebp)
jne 0f

darwin.S
72 /* If the return value pointer is NULL, assume no return value. */
73 cmpl $0,24(%ebp)
74 jne 0f

I think it'd be better to remove note about NULL RVALUE from docs.

With msys and mingw, ./configure and make work fine, but make install fails with a cryptic error and a message that ../install-sh could not be found. install-sh exists in the top-level project directory (at least after ./configure), but make attempts to use it with ../install-sh from what appears to be an architecture-specific directory (e.g. libffi-x.x.xx/i686-pc-mingw32/include when install-sh is at libffi-x.x.xx/install-sh). cp install-sh i686-pc-mingw32 && make install seems to work for me.

hi~
I'm using msys/mingw from mingw-builds to build libffi on win7 x86 32bit,
configure and make goes well, but make check fail many ...

here is a part of make check output ...

FAIL: libffi.call/cls_align_uint16.c output pattern test, is 12 4951 127 1 9320
13: 13 14271 140
res: 13 14271 140
12 4951 127 1 9320 13: 13 14271 140
res: 140 0 0
? should match 12 4951 127 1 9320 13: 13 14271 140
?es: 13 14271 140
?2 4951 127 1 9320 13: 13 14271 140
res: 13 14271 140
FAIL: libffi.call/cls_align_uint32.c output pattern test, is 12 4951 127 1 9320
13: 13 14271 140
res: 13 14271 140
12 4951 127 1 9320 13: 13 14271 140
res: 191 2097292 239
? should match 12 4951 127 1 9320 13: 13 14271 140
?es: 13 14271 140
?2 4951 127 1 9320 13: 13 14271 140
res: 13 14271 140
FAIL: libffi.call/cls_align_uint64.c (test for excess errors)
FAIL: libffi.call/cls_align_uint64.c output pattern test, is 12 4951 127 1 9320
13: 13 14271 140
res: 13 14271 140

12 4951 127 1 9320 13: 13 14271 140

nested_struct.exe and other test program crashed ...
Is this normal that build libffi on windows or I'm using incorrect configure ? ...
Sorry to disturb you :)
And sorry for my crappy English ...

I am not an assembler programmer, but, it appears to be a problem with libffi/src/x86/win32.S. According to the documentation, the prologue argument "FORCEFRAME" needs to be in angle brackets. Putting FORCEFRAME in angle brackets allows the code to compile.

<FORCEFRAME>

I discovered the resolution through this link:
http://www.masmforum.com/board/index.php?PHPSESSID=8d46cd4ecb1688be429ab49694ec53e6&topic=5252.0;wap2

It looks like this is actually correct, according to:
http://msdn.microsoft.com/en-us/library/01d2az3t.aspx

Where "FORCEFRAME" is a prologuearg.

This was discovered while trying to compile Ruby FFI, which has a copy of this library.

Related Issue:
ffi/ffi#326

On x86_64 GNU/Linux, with the current HEAD (c3c40e0):

$ cat crash.c 
#include <stdint.h>
#include <assert.h>
#include <ffi.h>

uint32_t uint32_function(void) { return 10u; }

int main(void)
{
  ffi_cif cif;
  uint32_t rc;
  uint32_t guard = 0xFFFFFFFF;

  assert (guard == 0xFFFFFFFF);

  if (ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 0, &ffi_type_uint32, NULL) == FFI_OK)
  {
      ffi_call(&cif, (void (*)(void))uint32_function, &rc, NULL);
  }
  assert (guard == 0xFFFFFFFF);
  return 0;
}
$ gcc -o crash -g -W -Wall -ansi -pedantic -I ../install/lib/libffi-3.0.13/include/ crash.c  -L../install/lib -lffi
$ ./crash
crash: crash.c:19: main: Assertion `guard == 0xFFFFFFFF' failed.
Aborted (core dumped)

win64 mingw build fails with libffi/src/x86/ffi.c:321:19: error: 'FFI_STDCALL' undeclared

After fixing the ifdef to exclude win64 too it works just fine.

When building libffi (for use with Python 2.7.6) on an older GCC platform, the library fails to link the *.so. The reason appears to be the expectation that if built with GCC, that '__builtin_expect()' is available. That builtin was not available with GCC until version 3 of the compiler.

I'd like to propose the following modification to the ffi_common.h header:

--- Modules/_ctypes/libffi/include/ffi_common.h Sun Nov 10 02:36:41 2013
+++ Modules/_ctypes/libffi/include/ffi_common.h.fix Mon Dec 16 08:23:56 2013
@@ -115,7 +115,7 @@

typedef float FLOAT32;

-#ifndef GNUC
+#if !defined(GNUC) || GNUC==2
#define __builtin_expect(x, expected_value) (x)
#endif
#define LIKELY(x) __builtin_expect(!!(x),1)

The libffi build unconditionally tries to run steps that require makeinfo whether it is present or not. This leads to build failures like this:

/builds/slave/try-l64-asan-00000000000000000/build/js/src/ctypes/libffi/missing: line 81: makeinfo: command not found
WARNING: 'makeinfo' is missing on your system.
You should only need it if you modified a '.texi' file, or
any other file indirectly affecting the aspect of the manual.
You might want to install the Texinfo package:
http://www.gnu.org/software/texinfo/
The spurious makeinfo call might also be the consequence of
using a buggy 'make' (AIX, DU, IRIX), in which case you might
want to install GNU make:
http://www.gnu.org/software/make/

In the Mozilla tree, we work around this by explicitly setting INFO_DEPS= in the generated Makefile.in. Kinda crummy, but it works. It would be nice if we had a more sanctioned way of avoiding this.

It's my first time using the library, I'm trying to compile it with clang and it seems I'm unable to configure includedir properly:

export CC=clang
export CFLAGS="-O3 -ffast-math -march=corei7 -Wall -fexceptions"
export CXX=clang++
export CXXFLAGS="-stdlib=libc++"
export LD=llvm-link

../configure
make
make install

The above gives this:

Making install in include
make[3]: Nothing to be done for `install-exec-am'.
test -z "/usr/local/lib/libffi-3.0.11/include" || ../../install-sh -c -d "/usr/local/lib/libffi-3.0.11/include"
/usr/bin/install -c -m 644 ffi.h ffitarget.h '/usr/local/lib/libffi-3.0.11/include'

then I tried to set:

./configure --includedir=/usr/local/include

And I got the same output. My include dir gets nothing, it aways ends in /usr/local/lib/libffi-3.0.11/include.

Hi, atgreen

I just check out libffi from git and installed on debian/6.0 x686_32 OS.

When I compile my c program, it shows errors:

undefined reference to ffi_type_sint32
undefined reference to ffi_call
collect2: ld returned 1 exit status

And I check the ffi.h header, but not find where is ffi_type_sint32 defined?

The core code like bellow:
Hi, guys

I am newer to libffi.

Now, I run into a compile error on debian/6.0 x86 system which I installed libffi use ./configurate --prefix=/usr config.

My simple code is:

#include <stdio.h>

#include <ffi.h>

int func0() {
    return 0;
}

int func1(int x) {
    return x;
}

int func2(int x, int y) {
    return x + y;
}

void *func_table[] = {
    (void *) func0,
    (void *) func1,
    (void *) func2,
}

int main(int argc, const char **argv) {
    int i;

    // some checks
    if (argc < 2) {
        exit(1);
    }

    int params_count = atoi(argv[1]);

    int params[2] = {0, 0};
    for (i = 0; i < 2; ++i) {
        if (scanf("%d", &params[i]) != 1) {
            exit(1);
        }
    }

    // define libffi call
    ffi_cif cif;
    ffi_type *args[] = { &ffi_type_sint, &ffi_type_sint };
    void *ptr_params[] = { &params[0], &params[1] };

    if (ffi_prep_cif( &cif, FFI_DEFAULT_ABI, params_count, &ffi_type_sint, args) ==FFI_OK) {
        // TODO
    } else {
        // TODO
    }

    return 0;
}

The libffi git repository includes generated or copied-in files like configure, config.guess, config.sub, compile, and so on. These files get updated every time the project is autoreconf'd. They shouldn't be checked into git; that either allows them to become stale (for instance, by checking in an updated configure.ac without configure), or creates a huge amount of diff noise (when checking in updates to the generated files).

Please consider dropping these files.

This is an old issue reported:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34311

and encountered again in (but distinct from):
https://github.com/atgreen/libffi/issues/53

If I understand correctly, this test can't really be 'fixed', but rather worked around by avoiding the overly aligned vector move, and using an unaligned memcpy instead.

Makefile.am:

toolexeclib_LTLIBRARIES = libffi.la

libffi.pc.in:

libdir=@libdir@
...
Libs: -L${libdir} -lffi

in my case, the library landed in lib64 but is searched in lib.

x86 stdcall always has 4-byte alignment.

I've fixed this on JNA (issue 300, branch issue-300).

Please make .tar.gz and .zip downloads available from GitHub similar to v3.0.9. These downloads are very useful for automation scripts only able to use HTTP/HTTPS and not able to use ftp://sources.redhat.com/pub/libffi/

$ ./configure
...
$ make
MAKE x86_64-apple-darwin11.1.0 : 0 * all-all
make: *** [all-all] Error 1

This should be escaped when encountered, instead of killing the build.

Hi,

I'm getting this error when trying to build for iOS. Any ideas?

/Prog/Frameworks/libffi/ios/src/arm/sysv.S:139:1: warning: macro defined with named parameters which are not used in macro body, possible positional parameter found in body which will have no effect
.macro ARM_FUNC_START name
^
/Prog/Frameworks/libffi/ios/src/arm/sysv.S:226:2: error: invalid instruction
stmeqia r2, {r0, r1}
^
:5:14: error: invalid symbol redefinition
.globl _$0; _$0:
^
/Prog/Frameworks/libffi/ios/src/arm/sysv.S:271:1: note: while in macro instantiation
ARM_FUNC_START ffi_closure_SYSV
^
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1

Thanks very much for the great work on libffi. It looks like it'd be great for a personal project of mine. That said, there is a little documentation problem.

Initially, I hoped that for libffi one could write code like this:

ffi_cif function_type;
{
    ffi_type *argument_types[30];

    /* generate argument_types here */

    ffi_status status = ffi_prep_cif(&function_type, FFI_DEFAULT_ABI,
                                     number_of_arguments,
                                     &ffi_type_void, argument_types);
    assert(FFI_OK == status);
}

but in the source the structure definition of ffi_cif seems to keep the pointers passed in to ffi_prep_cif in the arg_types and rtype fields (in ffi_prep_cif_core):

cif->abi = abi;
cif->arg_types = atypes;
cif->nargs = ntotalargs;
cif->rtype = rtype;

These kind of data ownership rules are undocumented. I'm still not entirely sure about the data ownership rules that libffi uses and I think it'd be nice if they were documented.

The following failure will occur when building with Clang:

libtool: compile: clang -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -DFFI_BUILDING -g -O2 -pipe -march=amdfam10 -mtune=amdfam10 -Wall -fexceptions -c ../src/x86/ffi64.c -fPIC -DPIC -o src/x86/.libs/ffi64.o /bin/bash ./libtool --tag=CC --mode=compile clang -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -DFFI_BUILDING -g -O2 -pipe -march=amdfam10 -mtune=amdfam10 -Wall -fexceptions -c -o src/x86/ffi.lo ../src/x86/ffi.c ../src/x86/unix64.S:357:17: error: invalid variant 'rel' .long .LUW0@rel ^ ../src/x86/unix64.S:399:17: error: invalid variant 'rel' .long .LUW5@rel ^

I discovered this issue on Gentoo. The Mozilla developers wrote a patch for it. Further information can be found in the downstream bug trackers:

https://bugs.gentoo.org/show_bug.cgi?id=417179
https://bugzilla.mozilla.org/show_bug.cgi?id=631928

Hi,

Would it be possible to make a tag for the new release?

libffi.so is installed in toolexeclibdir, which is set to be $libdir/$($CC -print-multi-os-directory). I see the purpose of this for those who build and install manually, but from a packager's standpoint, is incorrect behavior. It also causes problems for multilib setups because gcc -print-multi-os-directory prints ../lib64, when CFLAGS may include -m32. This could be solved by adding $CFLAGS to the print-multi-os-directory line, however, I still think it is incorrect behavior because if I specify --libdir=foo, I expect the library to be installed in foo.

The comment above this section mentions something about "these variables are only ever used when we cross-build to X86_WIN32", so perhaps that whole section should be disabled when this is not the case.

The x86-64 ABI does not require a rbp based stack frame (in fact gcc 4.6 onward by default wont emit any anymore).
It'd be a good idea to emit compatible ffi that allows walking thread via [rbp] indirections.

The primary reason for this is that it is probably impossible for libffi to emit eh_frames as defined by the dwarf standard.
Emitting proper stackframes potentially helps most code to still do proper unwinding.

The whole problem manifested, when I tried to do exception unwinding over language boundaries from within D,
which only uses bp to unwind stackframes and due to this fails at any libffi transition without any way to recover.

In particular i've set up transitions as:

D:

extern(C) void callback() { throw new SomeException(); }
int main()
{
    try { callC(&callback); } catch(SomeException e) {}
}

C:

funcptr _cb;
void callC(funcptr cb) 
{
  _cb = cb;
  ffi_call(... &indirection ...),
}

void indirection()
{
    _cb();
}

Now indirection() as well as callback() can only see stackframes down to ffi_call_unix64 when using rbp indirection.
This makes the whole exception unwinding blow up.

Hi, please, take a look at
https://bugs.gentoo.org/show_bug.cgi?id=457194
and attachment there. Could it be incorporated upstream, please?

When compiling for iOS I am getting:

src/arm/sysv.S:338:Unknown pseudo-op: .fpu
src/arm/sysv.S:338:Rest of line ignored. 1st junk character valued 118 (v).
src/arm/sysv.S:158:Unknown pseudo-op: .ifc
src/arm/sysv.S:158:Rest of line ignored. 1st junk character valued 34 (").

This leads me to believe that the older version of AS that apple ships with doesn't contain .ifc and .fpu.

I don't know ARM assembly, but it these functions could be rewritten to not use these pseudo-ops.

Thanks!
Mike

Hello,

The subject is something libffi does not support. I'm wondering whether this is just something that you did not get to, or is there a more inherent problem with supporting unions and structs-with-bitfields being passed by value?

Hi,

I'm using a 64-bit mac to compile but I want to create a 32-bit build, so I'm configuring like this:

./configure CC='gcc -arch i386' CXX='g++ -arch i386' --host=i386-apple-darwin --prefix=/ubase/i386

make eventually fails with:

libtool: compile: gcc -arch i386 -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -DFFI_BUILDING -g -O3 -fomit-frame-pointer -malign-double -fstrict-aliasing -ffast-math -Wall -fexceptions -MT src/x86/ffi.lo -MD -MP -MF src/x86/.deps/ffi.Tpo -c ../src/x86/ffi.c -fno-common -DPIC -o src/x86/.libs/ffi.o
../src/x86/ffi.c: In function 'ffi_prep_cif_machdep':
../src/x86/ffi.c:283: error: 'FFI_MS_CDECL' undeclared (first use in this function)
../src/x86/ffi.c:283: error: (Each undeclared identifier is reported only once
../src/x86/ffi.c:283: error: for each function it appears in.)
make[3]: *** [src/x86/ffi.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-all] Error 2

Any ideas?

Hi. I reported this bug against 3.0.4 back in 2008. Looking at 3.0.13 today, I see that the bug is still there. Since there seems to exist a bug tracker novadays, I'm refiling it here. Enjoy!

---8<---
Hi.

I'm trying to use libffi to create closures for native Java methods
for IBM JDK 1.6.0.1 on Gentoo/PPC64. The problem is that they don't
work, since .ffi_closure_LINUX64 assumes that r11 holds a pointer to
the closure structure. While the IBM runtime does indeed put this
pointer into r11 during the extraction of the function address and
TOC value, it restores the register to a previous value before
actually jumping to the function:

0x0000040003196a28:     std     r11,-8(r1)  <-- r11 is saved
0x0000040003196a2c:     ori     r11,r19,0
0x0000040003196a30:     std     r2,40(r1)
0x0000040003196a34:     ld      r2,0(r11)
0x0000040003196a38:     mtctr   r2
0x0000040003196a3c:     ld      r2,8(r11)
0x0000040003196a40:     ld      r11,-8(r1)  <-- r11 is restored
0x0000040003196a44:     bctrl               <-- call

As far as I can see, the 64-bit PowerPC ELF ABI Supplement does not
require that r11 holds the function pointer, it only reserves it as a
volatile register for this purpose. It also explicitly says that the
callee can't depend on r11 keeping the value put there by the caller
anyway. So I think libffi is abusing the ABI. It should be rather
simple to rewrite the code to use r2 as the context register instead,
and let .ffi_closure_LINUX64 load the correct TOC value itself after
it has saved the context pointer to r11 or whatever.

// Marcus

I had successfully tested version 3.0.11-rc3 with my work-in-progress port of python-ctypes on iOS.

I tried to use version 3.0.11 final for the same purpose, using the new xcode build system provided in pull requests in issues #15 and #16 :

• I manage to get libffi being built without any warning.
• I manually create an universal library out of the arm and i386 libraries

If I use this new library in my python build, it compiles and link without problem, but does not run anymore : the process halts with a SIGABRT in the simulator.

The signal is issued by assert(cinuse(p)); in do_check_inuse_chunk called by libc's free function, in a portion of code that has nothing to do with libffi.

I've double checked my results : when I build libffi (3.0.11 rc3 or final) with the build-ios.sh script that has been removed it all works fine.

As the new build system has no documentation or rationale, and I'm far from being an Xcode power user, I cannot alas provide any workaround for this problem. Right now I'll keep on using the previous build-ios.sh script.

/bin/bash ./libtool   --mode=compile /home/antoine/Documents/spksrc/toolchains/syno-88f5281/work/arm-marvell-linux-gnu/bin/arm-marvell-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I..  -I. -I../include -Iinclude -I../src -I/home/antoine/Documents/spksrc/cross/libffi/work-88f5281/install//usr/local/include  -I. -I../include -Iinclude -I../src -g -mfloat-abi=soft -I/home/antoine/Documents/spksrc/cross/libffi/work-88f5281/install//usr/local/include  -MT src/arm/sysv.lo -MD -MP -MF $depbase.Tpo -c -o src/arm/sysv.lo ../src/arm/sysv.S &&\
    mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  /home/antoine/Documents/spksrc/toolchains/syno-88f5281/work/arm-marvell-linux-gnu/bin/arm-marvell-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -I/home/antoine/Documents/spksrc/cross/libffi/work-88f5281/install//usr/local/include -I. -I../include -Iinclude -I../src -g -mfloat-abi=soft -I/home/antoine/Documents/spksrc/cross/libffi/work-88f5281/install//usr/local/include -MT src/arm/sysv.lo -MD -MP -MF src/arm/.deps/sysv.Tpo -c ../src/arm/sysv.S  -fPIC -DPIC -o src/arm/.libs/sysv.o
../src/arm/sysv.S: Assembler messages:
../src/arm/sysv.S:338: Error: unknown pseudo-op: `.fpu'

That's with 3.0.10 and latest master too. Am I missing some configuration here?

Thanks

libffi 3.0.12 introduced a few changes that cause pkginfo to be out of sync with the installation when building on OS X 10.8.2 (Mountain Lion). This causes an error through dependent builds.
gtk+/gio example.

libffi 3.0.11:

• installed libraries in ${PREFIX}/lib.
• specified libdir=${exec_prefix}/lib in pkginfo/libffi.pc.

libffi 3.0.12:

• installed libraries in ${PREFIX}/lib/X86_64.
• specified libdir=${exec_prefix}/lib in pkginfo/libffi.pc.

git bisect can't identify the specific cause because a number of the commits are unbuildable for other reasons. However, there are "good" commits before the jrails patch and mostly bad ones after.

In https://bugzilla.mozilla.org/show_bug.cgi?id=778414 i've found out that libffi was checking for unwind section type support in the compiler, but not in the whole toolchain. When using clang on OpenBSD, the compiler supports it, but our ancient ld (binutils 2.15) doesnt support it. configure ends up wrongly defining HAVE_AS_X86_64_UNWIND_SECTION_TYPE to 1, and hilarity ensues later on.

Backporting https://hg.mozilla.org/mozilla-central/diff/94dc6f0b5f8b/js/src/ctypes/libffi/configure.ac to libffi's git would ensure the patch local to mozilla wouldnt get lost in future upgrades, as targeted in https://bugzilla.mozilla.org/show_bug.cgi?id=810631

If needed i can work that into a pull request...

Using libffi (3.0.13), compiling on Xcode 5.0.2, three warnings are generated:

…Pods/libffi/ios/src/x86/ffi.c:362:21: Ambiguous expansion of macro 'alloca'
…Pods/libffi/ios/src/x86/ffi.c:489:26: Ambiguous expansion of macro 'alloca'
…Pods/libffi/ios/src/x86/ffi.c:785:21: Ambiguous expansion of macro 'alloca'

alloca is defined in both ffi_common.h and alloca.h (a built-in library).

It looks like this #ifndef isn't working for some reason:

#ifndef alloca
# define alloca __builtin_alloca
#endif

Compiling on Solaris 11 x86 64bit with Sun Studio 12.3 compiler

The combination of 64bit and -D__i386__ creates a situation where this issue occurs:

/bin/sh ./libtool --tag=CC   --mode=link cc -m64  -D__i386__  -no-undefined -version-info `grep -v '^#' ../libtool-version`  '-L/usr/local/lib' '-R/usr/local/lib'  -L/usr/local/lib -R/usr/local/lib -o libffi.la -rpath /libffi/lib src/prep_cif.lo src/types.lo src/raw_api.lo src/java_raw_api.lo src/closures.lo                           src/x86/ffi64.lo src/x86/unix64.lo src/x86/ffi.lo src/x86/sysv.lo         -lpthread -lthread
libtool: link: cc -m64 -G -z defs -h libffi.so.6 -o .libs/libffi.so.6.0.1  src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/ffi64.o src/x86/.libs/unix64.o src/x86/.libs/ffi.o src/x86/.libs/sysv.o   -R/usr/local/lib -L/usr/local/lib -lpthread -lthread -lc  -m64  
Undefined                       first referenced
 symbol                             in file
ffi_prep_raw_closure_loc            src/.libs/raw_api.o
ld: fatal: symbol referencing errors. No output written to .libs/libffi.so.6.0.1

Removing -D__i386__ fixes this as then the "System specific configurations" redefines in src/x86/ffitarget.h don't mess with your compile.

Posted here for the record so it gets googled. Can be closed as "solved".

I am getting the following error in ffi_common.h:
Unknown type name ffi_status
Unknown type name ffi_cif

These types are clearly being defined in the main ffi_arm.h and ffi_i386.h

Hi,

In the selinux_enabled_check() function, the selinuxfs mountpoint is hardcoded to /selinux

Libselinux is mounting the selinuxfs under /sys/fs/selinux for some times now and falling back to /selinux only of the former is not available during early boot (mainly if no initramfs is used).

Several distributions have even started to remove the /selinux directory.

You probably want to test both "/sys/fs/selinux" and "/selinux" in that order.

The fixes are trivial, see the diff in http://hg.python.org/cpython/rev/5e71f5cfd233 against the libffi 3.0.13 copy included with CPython.

Please see http://llvm.org/bugs/show_bug.cgi?id=12207. In particular, this has come up in Python, see http://bugs.python.org/issue17136.

Compiling on Solaris 11 x86 64bit using the Sun Studio 12.3 compiler

"src/x86/ffi64.c", line 43: syntax error before or at: __int128_t
"src/x86/ffi64.c", line 46: member cannot be function: ffi_call_unix64
"src/x86/ffi64.c", line 59: warning: unnamed struct member

Please push a tag for the newly released v3.0.11 commit.

While working on #101, I started enabling some of the closure tests (closure_fn0, closure_fn1, etc) for multiple ABIs. I discovered that FFI_THISCALL closures seem to be broken if the first argument type does not get passed in a register, which occurs either if that first argument has floating-point type or takes up more than 4 bytes. closure_thiscall.c doesn't trigger this, but all the other closure tests do if run with FFI_THISCALL.

I've confirmed that my recent changes to the closure trampolines did not cause this issue; the issue existed before that as well.

Here are some of the failures (to reproduce, modify the tests to use ABI_NUM rather than FFI_DEFAULT_ABI, and apply ABI_ATTR to the function pointer typedef):

FAIL: libffi.call/closure_fn0.c -W -Wall -O0 -DABI_NUM=FFI_THISCALL -DABI_ATTR=__THISCALL__ output pattern test, is 88 0 2 0 4 127 0 7 0 1076035584 10 0 1094713344 13 19 21 3: -2124218074
res: -2124218074
? should match 1 2 3 4 127 429 7 8 9 10 11 12 13 19 21 1 3: 680
res: 680

FAIL: libffi.call/closure_fn1.c -W -Wall -O0 -DABI_NUM=FFI_THISCALL -DABI_ATTR=__THISCALL__ output pattern test, is 0 1 2 3 -13107 5 6 8 9 10 11 12 13 19 21 1 3: -12983
res: -12983
? should match 1 2 3 4 127 5 6 8 9 10 11 12 13 19 21 1 3: 255
res: 255

FAIL: libffi.call/closure_fn2.c -W -Wall -O0 -DABI_NUM=FFI_THISCALL -DABI_ATTR=__THISCALL__ output pattern test, is 0 0 0 0 0 5 6 8 9 10 11 12 13 19 21 1 3: 118
res: 118
? should match 1 2 3 4 127 5 6 8 9 10 11 12 13 19 21 1 3: 255
res: 255

FAIL: libffi.call/closure_fn3.c -W -Wall -O0 -DABI_NUM=FFI_THISCALL -DABI_ATTR=__THISCALL__ output pattern test, is 0 1 2 3 4 5 6 7 0 1075970048 11 12 13 19 21 1 3: 1075970156
res: 1075970156
? should match 1 2 3 4 5 6 7 8 9 10 11 12 13 19 21 1 3: 135
res: 135

FAIL: libffi.call/closure_fn4.c -W -Wall -O0 -DABI_NUM=FFI_THISCALL -DABI_ATTR=__THISCALL__ output pattern test, is 132 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3: 135
res: 135
? should match 1 2 3 4 127 429 7 8 9 10 11 12 13 19 21 1 3: 680
res: 680

FAIL: libffi.call/closure_fn5.c -W -Wall -O0 -DABI_NUM=FFI_THISCALL -DABI_ATTR=__THISCALL__ output pattern test, is 128 0 0 0 0 0 0 0 0 0 0 11 0 0 0 0 3: 142
res: 142
? should match 1 2 3 4 127 429 7 8 9 10 11 12 13 19 21 1 3: 680
res: 680

FAIL: libffi.call/closure_fn6.c -W -Wall -O0 -DABI_NUM=FFI_THISCALL -DABI_ATTR=__THISCALL__ output pattern test, is 112 0 0 0 0 0 0 2 0 0 1076101120 0 1094713344 13 0 0 3: -2124152702
res: -2124152702
? should match 1 2 3 4 127 429 7 8 9 10 11 12 13 19 21 1 3: 680
res: 680

FAIL: libffi.call/closure_loc_fn0.c -W -Wall -O0 -DABI_NUM=FFI_THISCALL -DABI_ATTR=__THISCALL__ output pattern test, is 3 0 2 0 4 127 0 7 0 1076035584 10 0 1094713344 13 19 21 3: -2124218159
res: -2124218159
? should match 1 2 3 4 127 429 7 8 9 10 11 12 13 19 21 1 3: 680
res: 680

The new ABI support in the 32-bit x86 port from changes the value of FFI_TRAMPOLINE_SIZE from 10 to 52, breaking old applications linked to the new library.

I was able to reproduce in the python test suite like so...

gdb --args python3.4-dbg /usr/lib/python3.4/ctypes/test/runtests.py \
  test_as_parameter.py

(old python binary with new libffi binary)

I'm trying to build libffi with xcode 4.6 for my ipad which runs iOS 6.1, but I'm getting,

/Users/ivan/Downloads/libffi-3.0.13 5/ios/src/arm/sysv.S:226:2: error: invalid instruction
 stmeqia r2, {r0, r1}
 ^
<instantiation>:5:14: error: invalid symbol redefinition
 .globl _$0; _$0:
             ^
/Users/ivan/Downloads/libffi-3.0.13 5/ios/src/arm/sysv.S:271:1: note: while in macro instantiation
ARM_FUNC_START ffi_closure_SYSV
^
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1

If I try to build for simulator everything works fine, but I need to build for device.

I also try running

xcodebuild -target "libffi iOS" -sdk iphoneos

but I'm getting

** BUILD FAILED **


The following build commands failed:
    CompileC "build/libffi.build/Release-iphoneos/libffi iOS.build/Objects-normal/armv7/sysv.o" ios/src/arm/sysv.S normal armv7 assembler-with-cpp com.apple.compilers.llvm.clang.1_0.compiler
(1 failure)

When I run

xcodebuild -target "libffi iOS" -sdk iphonesimulator -arch i386

there is no errors.

Do you know why build for iOS device is failing?

Note: I tried running generate-ios-source-and-headers.py before build, but it also fails.

thiscall and fastcall correspond to regparm 1 and 2, but some software (such as GRUB) uses regparm 3.

First time libffi user, I'm sure pretty typically got segfault and then gdb showed that a register, instead of pointer to sting, contained actual string chars. So, libffi does extra dereferencing, and ffi_call's AVALUES argument is actually AVALUEPTRS.

Ok, but that means even if I have values on my hands, I need to store them temporarily somewhere, just to pass pointers to libffi. That means that with typical dynamic language (main usecase for libffi of course) I need to allocate memory to hold values, then memory to hold pointers to these values, then pass it all to libffi which will of course munge it again and allocate more memory (yes, ideally that all happens on stack, but still).

But come on, most of values being passed fit into void *, so they could go directly to AVALUE slot, i.e. be passed by value, not by reference. That's even doable - just need to define new "value types" ffi_type_pointer_by_v and friends so compatibility will be there. Yeah, it's unclear if it's worth doing. What's clear is that because such things haven't been done right from the start, we have such bloaty software around (Firefox damn slow writing this and Chromium just crashed - all on 3Gb RAM machine).

On simulator we get unhandled exception crash with the following code:

void test() {
    [NSException raise:@"test" format:@"test"];
}

int main(int argc, char *argv[])
{
    ffi_cif cif;
    ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 0, &ffi_type_void, NULL);
    @try {
        ffi_call(&cif, test, NULL, NULL);
    } @catch(NSException* ex) {
        NSLog(@"%@", ex);
    }
}

The diff for the modified xcode project: http://pastebin.com/RKf5PSnn

Test Run By fink-bld on Fri Sep  6 15:54:25 2013
Native configuration is powerpc-apple-darwin8.11.0

                === libffi tests ===

Schedule of variations:
    unix

Running target unix
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target
.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../testsuite/config/default.exp as tool-and-target-specific interface f
ile.
Running ../../testsuite/libffi.call/call.exp ...
Running ../../testsuite/libffi.special/special.exp ...
FAIL: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ execution test
FAIL: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ execution t
est
FAIL: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ execution test
FAIL: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ execution t
est
FAIL: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ execution test
FAIL: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ execution t
est
FAIL: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ execution test
FAIL: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ execution t
est

                === libffi Summary ===

# of expected passes            1803
# of unexpected failures        8
# of unsupported tests          55
make[3]: *** [check-DEJAGNU] Error 1
make[3]: Leaving directory `/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3
.0.13/powerpc-apple-darwin8.11.0/testsuite'
make[2]: *** [check-am] Error 2
make[2]: Target `check' not remade because of errors.
make[2]: Leaving directory `/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3
.0.13/powerpc-apple-darwin8.11.0/testsuite'
Making check in man
make[2]: Entering directory `/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-
3.0.13/powerpc-apple-darwin8.11.0/man'
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory `/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3
.0.13/powerpc-apple-darwin8.11.0/man'
make[2]: Entering directory `/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-
3.0.13/powerpc-apple-darwin8.11.0'
make[2]: Nothing to be done for `check-am'.
make[2]: Leaving directory `/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3
.0.13/powerpc-apple-darwin8.11.0'
make[1]: *** [check-recursive] Error 1
make[1]: Target `check' not remade because of errors.

from testsuite/libffi.log:

Setting LD_LIBRARY_PATH to .::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs:.::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs
FAIL: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ execution test
Executing on host: gcc ../../testsuite/libffi.special/unwindtest_ffi_call.cc   -shared-libgcc -lstdc++ -O0 -W -Wall -I/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../include -I../../testsuite/../include  -I/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../include/.. -L/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs  -shared-libgcc -lffi -lm   -o ./unwindtest_ffi_call.exe    (timeout = 300)
PASS: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ (test for excess errors)
Setting LD_LIBRARY_PATH to .::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs:.::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs
terminate called after throwing an instance of 'int'
FAIL: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ execution test
Executing on host: gcc ../../testsuite/libffi.special/unwindtest.cc   -shared-libgcc -lstdc++ -O2 -I/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../include -I../../testsuite/../include  -I/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../include/.. -L/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs  -shared-libgcc -lffi -lm   -o ./unwindtest.exe    (timeout = 300)
PASS: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ (test for excess errors)
Setting LD_LIBRARY_PATH to .::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs:.::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs
FAIL: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ execution test
Executing on host: gcc ../../testsuite/libffi.special/unwindtest_ffi_call.cc   -shared-libgcc -lstdc++ -O2 -I/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../include -I../../testsuite/../include  -I/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../include/.. -L/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs  -shared-libgcc -lffi -lm   -o ./unwindtest_ffi_call.exe    (timeout = 300)
PASS: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ (test for excess errors)
Setting LD_LIBRARY_PATH to .::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs:.::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs
terminate called after throwing an instance of 'int'
FAIL: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ execution test
Executing on host: gcc ../../testsuite/libffi.special/unwindtest.cc   -shared-libgcc -lstdc++ -O3 -I/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../include -I../../testsuite/../include  -I/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../include/.. -L/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs  -shared-libgcc -lffi -lm   -o ./unwindtest.exe    (timeout = 300)
PASS: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ (test for excess errors)
Setting LD_LIBRARY_PATH to .::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs:.::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs
FAIL: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ execution test
Executing on host: gcc ../../testsuite/libffi.special/unwindtest_ffi_call.cc   -shared-libgcc -lstdc++ -O3 -I/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../include -I../../testsuite/../include  -I/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../include/.. -L/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs  -shared-libgcc -lffi -lm   -o ./unwindtest_ffi_call.exe    (timeout = 300)
PASS: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ (test for excess errors)
Setting LD_LIBRARY_PATH to .::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs:.::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs
terminate called after throwing an instance of 'int'
FAIL: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ execution test
Executing on host: gcc ../../testsuite/libffi.special/unwindtest.cc   -shared-libgcc -lstdc++ -Os -I/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../include -I../../testsuite/../include  -I/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../include/.. -L/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs  -shared-libgcc -lffi -lm   -o ./unwindtest.exe    (timeout = 300)
PASS: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ (test for excess errors)
Setting LD_LIBRARY_PATH to .::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs:.::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs
FAIL: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ execution test
Executing on host: gcc ../../testsuite/libffi.special/unwindtest_ffi_call.cc   -shared-libgcc -lstdc++ -Os -I/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../include -I../../testsuite/../include  -I/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../include/.. -L/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs  -shared-libgcc -lffi -lm   -o ./unwindtest_ffi_call.exe    (timeout = 300)
PASS: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ (test for excess errors)
Setting LD_LIBRARY_PATH to .::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs:.::/Volumes/Isolde/fink.build/libffi6-3.0.13-1/libffi-3.0.13/powerpc-apple-darwin8.11.0/testsuite/../.libs
terminate called after throwing an instance of 'int'
FAIL: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ execution test
testcase ../../testsuite/libffi.special/special.exp completed in 12 seconds

                === libffi Summary ===

# of expected passes            1803
# of unexpected failures        8
# of unsupported tests          55
runtest completed at Fri Sep  6 16:04:46 2013

Same tests fail on version 3.0.11 (reproduced now).
I /think/ same tests failed with 3.0.9, but I have to dig up that version and re-run to confirm.