[Openmcl-devel] Re: Helmut Eller's ffigen changes

[Gary Byers]

On Wed, 8 Dec 2004 rm at fabula.de wrote:

> i just downloaded and compiled Helmut's version. I needed to apply the patches
> for "__int128_t" to get i working and i also rewrote h-to-ffi.sh (so we don't
> need to use/distribute the gcc include files). Everything seems to work as
> expected, but: there seems to be a new version of stdarg.h that causes ffigen
> to emit code that OpenMCL can't grok. Here's a sample header file:
>
> --------------------------- test.h --------------------------------------
>  #include <stdio.h>
>
>   void my_fun (int);
>
> -------------------------------------------------------------------------
>
>
> which will generate
>
> --------------------------- test.i --------------------------------------
>  ....
>
> #define __need___va_list
> # 1 "/usr/lib/gcc-lib/powerpc-linux/3.3.3/include/stdarg.h" 1 3 4
> # 37 "/usr/lib/gcc-lib/powerpc-linux/3.3.3/include/stdarg.h" 3 4
> #undef __need___va_list
>
>
>
>
> #define __GNUC_VA_LIST
> typedef __builtin_va_list __gnuc_va_list;
> # 54 "/usr/include/libio.h" 2 3 4
>
>  ...
> -------------------------------------------------------------------------
>
> which will result in
>
> --------------------------- test.ffi ------------------------------------
>
>  ...
>
>  ("/usr/include/libio.h" 52) "__need___va_list" "")
> (undef-macro "__need___va_list")
> (macro ("/usr/lib/gcc-lib/powerpc-linux/3.3.3/include/stdarg.h" 42) "__GNUC_VA_LIST" "")
> (type ("/usr/lib/gcc-lib/powerpc-linux/3.3.3/include/stdarg.h" 43)
>  "__gnuc_va_list"
>  (builtin-va-list ()))
> (undef-macro "_IO_va_list")
>
>  ...
>
> -------------------------------------------------------------------------
>
>
> Now, that builtin-va-list seems to come from ffi.c:
>
>  static ffi_primitive_name_map ffi_primitive_names[] =
> {
>   {"int", "int"},
>   {"char", "char"},
>   {"float", "float"},
>   {"double", "double"},
>   {"long double", "long-double"},
>   {"void", "void"},
>   {"long int", "long"},
>   {"unsigned int", "unsigned"},
>   {"long unsigned int", "unsigned-long"},
>   {"long long int", "long-long"},
>   {"long long unsigned int", "unsigned-long-long"},
>   {"short int", "short"},
>   {"short unsigned int", "unsigned-short"},
>   {"signed char", "signed-char"},
>   {"unsigned char", "unsigned-char"},
>   {"complex int", "complex-int"},
>   {"complex float", "complex-float"},
>   {"complex double", "complex-double"},
>   {"complex long double", "complex-long-double"},
>   {"__builtin_va_list", "builtin-va-list"},    <--------------
>   {"_Bool", "bool"},
>   {NULL, NULL}
> };
>
> I wasn't able to find any reference to builtin-va-list so far, so maybe someone
> on this list can enlighten me?

The ffi_primitive_names[] table is supposed to explain how to map from
(the printed representation of) a GCC builtin-type to some lispy symbol
that'll be written to the .ffi file.  I think that there's actuallly
a way to get GCC to spit out the left-hand-side of this table; if GCC
is AltiVec-aware (as it is on Darwin), there'll be more/different
built-in types.  (Apparently, __int128_t is now a standard builtin
GCC type.  Some of these things could - and may have been in the past -
defined with typedef, but there are apparently advantages to having
the compiler have some intrinsic awareness of them.)

There's a similar table in "ccl:library;parse-ffi.lisp", which maps
the entries on the right-hand-side of the table above (interned as
keywords) to type names in OpenMCL's FFI. (The "table" is actually
an ECASE that we're presumably not satisfying, in the functon
REFERENCE-FFI-TYPE.)

I think that adding a (:BUILTIN-VA-LIST '(:primitive (* :void))) clause is
probably close enough (there probably isn't too much interesting stuff
you can do with a C varargs "list" from the lisp side, and treating it
as "void *" is probably reasonable.)

(It -might- also be reasonable to change the ECASE to a CASE and
handle anything unknown as "void *".)