ffi-test-main.c fails on FreeBSD

In conjunction with getting Open Cobalt running on FreeBSD I have been
looking into the problems with SqueakFFIPrims on FreeBSD and have
reached a point that is beyond my understanding. I am not sure if the
fix should come from the VM side or the FreeBSD port maintainer.

I needed to get source code back into the ports tree so I did a make
in /usr/ports/lang/squeak. I already had the 3.9 tarball, so that just
repopulated the source and did the initial build.

In the "files" folder I found patch files typical for a FreeBSD port.
These patch source files from a generic tarball to work with FreeBSD.
The one of interest was

patch-platforms__unix__plugins__SqueakFFIPrims__ffi-config

which contains

----x-----x-----
--- platforms/unix/plugins/SqueakFFIPrims/ffi-config.org        Wed Apr
26 20:27:53 2006
+++ platforms/unix/plugins/SqueakFFIPrims/ffi-config    Wed Apr 26
20:29:00 2006
@@ -39,6 +39,7 @@

 case ${abi} in
    linux)             abi=sysv;;
+    freebsd*)          abi=sysv;;
    darwin*)           abi=darwin;;
    *)                 abi=libffi; lib="-lffi";;
 esac
-----x-----x-----

I then had the folder

work/Squeak-3.9-7/platforms/unix/plugins/SqueakFFIPrims

In it is a file 00README which explains how to test FFI.

It says to run ffi-test-config but I have no such file.

It says to type "make" to build a test suite but the build failed.

It says to try with make CPU=any ABI=libffi LIB=-lffi

which also failed. I traced the problem to the gcc search paths for
includes and libraries -- turns out FreeBSD only searches /usr/include
and /usr/lib when the required files are in /usr/local/include
and /usr/local/lib.

After some fiddling I finally had a "main" to test. It failed:
ffi-test-main.c failed at line 361. Here is a bit from that file, ending
with line 361:

   ffiInitialize();
   for (ul= 0;  ul < 15;  ++ul)
     ffiPushSingleFloat(fa[ul]);
   GO(FFITypeSingleFloat, many);
   f= ffiReturnFloatValue();
   ffiCleanup();
   CHECK(f - ff < FLT_EPSILON);

I worked out the CHECK macro but could not find what FLT_EPSILON is. At
that point I decided to stop and come to you for help.

Where do I go from here?

--
Gary Dunn, Honolulu
[hidden email]
http://openslate.net/
http://e9erust.blogspot.com/
Sent from Slate001

> define FLT_EPSILON as something like 1e-20 and rewrite the check as CHECK(fabs(f - ff) < FLT_EPSILON)?
>
> In math epsilon is a small value tending towards zero.  The intent here is to check that you get back something close to ff without assuming that the floating-point arithmetic involved in many is exact enough to return ff.

Ok, the implication then for testing is that


ffiPushSingleFloat
ffiReturnFloatValue

modify the floating point value slightly, if that is acceptable
then you need to epsilon test.

also GCC seems to define
#define FLT_EPSILON 1.19209290e-07F
across all flavours of CPUs and float word lengths.
perhaps via "float.h"


--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================

I can report progress but no solution.

1. Since ffi-test-main failed to build with a simple "make" I had
assumed I needed to use libffi. I added a print statement to show the
values at the point of failure at line 361, the CHECK statement:

   ffiInitialize();
   for (ul= 0;  ul < 15;  ++ul)
     ffiPushSingleFloat(fa[ul]);
   GO(FFITypeSingleFloat, many);
   f= ffiReturnFloatValue();
   ffiCleanup();

   printf("%g %g %g %g\n", f, ff, f - ff, FLT_EPSILON);

   CHECK(f - ff < FLT_EPSILON);

It gave f and ff to be identical, f - ff zero, and FLT_EPSILON a very
small value. The strange thing was that the test did not fail. I
commented out my print statement and it failed. Weird.

I noticed I was not seeing the output from puts statements. Recalling
that this is typically a macro I looked to see if it had been defined,
and found this near the top of the file:

#if 0
# define dprintf(ARGS)  printf ARGS
# define puts(ARG)      puts(ARG)
#else
# define dprintf(ARGS)
# define puts(ARG)
#endif

I changed the zero to one and the output was verbose. No failure, even
with my print statement commented out.

I suspect there is some tricky coding here that works on some versions
of C and not others. The preprocessor, especially.

So I got to wondering why make without args failed. I traced the problem
to these lines from the Makefile

CPU=    $(shell ./ffi-config -cpu)
ABI=    $(shell ./ffi-config -abi)
LIB=    $(shell ./ffi-config -lib)

Running them manually gave x86, sysv and blank, but

OBJ=    ffi-test-main.o ffi-test.o $(CPU)-$(ABI).o $(CPU)-$(ABI)-asm.o

resolved to ffi-test-main.o ffi-test.o -.o --asm.o

which caused make to complain that it did not know how to make -.o.

I substituted like this

#OBJ=    ffi-test-main.o ffi-test.o $(CPU)-$(ABI).o $(CPU)-$(ABI)-asm.o
OBJ=   ffi-test-main.o ffi-test.o x86-sysv.o x86-sysv-asm.o

and the build completed.

Eventually I figured out that the shell construct works in gnu make.
FreeBSD does not use gnu make. It is available as gmake. I put back the
Makefile and used gmake and got a good build.

The results are inconclusive. The output is

slate01# ./main
passed ffi assertions (0 failed)
Problem passing 64bit structures

Is that because I am not using a 64bit CPU? Is that a show stopper?
Apparently not.

The thing is, this does not fix the real problem. If I load my 3.9 image
and install the FFI package from SqueakMap, then run the FFI-Tests in
SUnit runner I get 21 run, 0 passes, 0 expected failures, 0 failures, 21
errors, 0 unexpected passes. When I click on a result and open a
debugger I find

Error: Unable to find function address

invokeWithArguments: argArray
       "Manually invoke the receiver, representing an external function."
       <primitive: 'primitiveCalloutWithArgs' module:'SqueakFFIPrims'>
       ^self externalCallFailed



externalCallFailed
       "Raise an error after a failed call to an external function"
       | errCode |
       errCode := ExternalFunction getLastError. "this allows us to look at
the actual error code"
       ^self error: (ExternalFunction errorMessageFor: errCode).



error: aString
       "Throw a generic Error exception."

       ^Error new signal: aString


If the  ffi-test-main.c tests are passing, why are the SUnit tests all
failing? Is that 64bit thing a big deal?

--

Gary Dunn, Honolulu
[hidden email]
http://openslate.net/
http://e9erust.blogspot.com/
Sent from Slate001