[Openmcl-devel] Trouble with ffigen

[Gary Byers]

On Thu, 3 Feb 2005, David Steuber wrote:

> On Feb 3, 2005, at 3:06 PM, Helmut Eller wrote:
>
> > I wrote my version for Linux/x86 and the -g3 trick may not work on
> > PPC.  It assumes that gcc emits macro definitions for the debugger,
> > but not all debugging information formats support macro definitions.
> > I think the dwarf2 format supports macro definitions and you should
> > invoke ffigen with  -g3 -gdwarf-2.
>
> That did the trick!  There are also a bunch of macro forms ahead of my
> file:
>
> <trimmed stuff>
> (macro ("test.h" 65) "__ppc__" "1")
> (macro ("test.h" 66) "__POWERPC__" "1")
> (macro ("test.h" 67) "__NATURAL_ALIGNMENT__" "1")
> (macro ("test.h" 68) "__MACH__" "1")
> (macro ("test.h" 69) "__APPLE__" "1")
> (type ("test.h" 2)
>   "my_type"
>   (unsigned ()))
> (macro ("test.h" 3) "A_CONSTANT" "42")
> (function ("test.h" 4)
>   "my_funk"
>   (function
>    ((int ()) (int ()) )
>    (int ())) (extern))
>
> Are those normal?  They look like stuff that would be #define(d) going
> in.
>

Yes.  There's generally no way for an automated process to distinguish
between:

#define SOMETHING_TO_CONTROL_CONDITIONAL_COMPILATION 1

and

#define MEANINGFUL_CONSTANT 1


> Stumbling through gdb, I did find that with my previous command line
> arguments, ffi_debug_define() and related functions were not being
> called.
>
> I notice that function argument names are not getting into the ffi
> file.  Is there a way to do that?  Would that break
> ccl::parse-standard-ffi-files?

I'm not sure that parameter names from C function prototypes are even
available at the point where ffigen (modified GCC frontend) spits out
the (FUNCTION ...) forms above.

If there are available and you wanted to include them in the .ffi
output, you'd either have to modify CCL::PARSE-STANDARD-FFI-FILES
to

 a) ignore the parameter names

 b) include the names in the .cdb file (and make parallel changes
    to code like the #_ reader macro.)

The name of the parameter might make error messages clearer in some
cases, and might be useful for displaying arglist information in a
development environment.  (All that #_ really cares about is the
number and types of the foreign arguments,)