Re: about header file parsing

["Marc Nieper-Wißkirchen" <marc.nieper@gmail.com>]

How would you handle, for example, gmp's header file?
https://gmplib.org/repo/gmp/file/default/gmp-h.in

Almost all of the public API is behind #define's. So even if the
gcc_jit_context is filled with the functions that are declared in the
header, one still needs to know the ABI of GMP to know which functions
to call.

In order to make it work in the general case (if this is at all
possible), I think one has to turn the C frontend of GCC into a
library (like libgccjit has turned the GCC middle/backend into a
library). This hypothetical library X has its own context K that is
populated by expanding and parsing the relevant header files.

In this context K, we can then ask for expansion of strings of C
tokens (e.g. in expression or statement context). Library X then
returns the expansion in term of, say, a C-specific GENERIC tree,
which can then be converted into/wrapped into a gcc_jit_object.

-- Marc

Am Mi., 9. Jan. 2019 um 16:43 Uhr schrieb David Malcolm <dmalcolm@redhat.com>:
>
> On Wed, 2019-01-09 at 16:13 +0100, Basile Starynkevitch wrote:
> > On 1/9/19 4:03 PM, akrl wrote:
> > > Sorry I try to explain it better.
> > > I was thinking to a gcc plugin (or potentially something else)
> > > that
> > > given a C file produce the libgccjit code necessary to fill a
> > > context
> > > with what is in the source file.
> >
> > That could not work in general, because C has macros (think of the
> > `EOF`
> > macro constant in `<stdio.h>`) that have no equivalent in libgccjit.
>
> Although possibly not working "in general" I think it could work for
> most important cases.   A macro in C typically can be handled as either
> a client-side function invocation in libgccjit, or as a libgccjit
> function.
>
> For example, CPython has various reference-counting macros:
>
>  #define Py_XDECREF(op) do { if ((op) == NULL) ; else Py_DECREF(op); } while (0)
>
> and in my "coconut" JIT-compiler for CPython I implement this as a
> libgccjit function:
>
> https://github.com/davidmalcolm/coconut/blob/master/coconut/compiler.py
> #L501
>
> (effectively treating it as a static inline function).
>
> > And
> > in practice C macros are very important (and a lot of API for C are
> > using macros, see also macros such as WIFEXITED in wait(2) on some
> > Linux
> > system).
> >
> > We have to admit that C and libgccjit are different "languages" (even
> > if
> > conceptually very close). And a C API is not exactly a set of
> > "objects"
> > that libgccjit can handle.
>
> They're not the same, but it is important that libgccjit be able to
> interoperate well with C APIs.
>
> Dave