Re: about header file parsing

[akrl <akrl@sdf.org>]

David Malcolm <dmalcolm@redhat.com> writes:

> On Wed, 2019-01-09 at 11:12 +0000, akrl wrote:
>> On  8 January 2019 18:21, David Malcolm <dmalcolm@redhat.com> wrote:
>>
>>     On Tue, 2019-01-08 at 10:50 +0000, akrl@sdf.org wrote:
>>     > Hi all,
>>     > I have a basic question.
>>     > Is there a way to ask libgccjit to parse a conventional .h
>> file?
>>
>>     Sadly, no.
>>
>>     > Or alternatively is there a way to have an header file parsed
>> and
>>     > converted in the equivalent libgccjit api calls?
>>
>>     Having a standard way to do this would be useful.
>>
>>     > I ask this because I noticed that, if you jit some code that
>> have to
>>     > inter-operate with non jitted code, maintaining two duplicated
>>     > definitions
>>     > of all data structures can be quite painful if these are not
>> trivial.
>>
>>     I agree that this is a nuisance.
>>
>>     > Alternatively what's the suggested work flow?
>>
>>     One idea I came up with was to use libabigail:
>>       https://sourceware.org/libabigail/
>>     to generate an ABI description e.g. via abidw:
>>       https://sourceware.org/libabigail/manual/abidw.html
>>     which emits an XML file, and then have a pre-canned way of
>> populating a
>>     gcc_jit_context from such an abigail ABI representation.
>>
>>     This code doesn't exist yet, though (but would just need writing
>> once).
>>
>>     Dave
>>
>>     > Best Regards
>>     >   Andrea
>>     >
>>
>> I think the idea of having something like a gcc plugin that once is
>> parsed
>> compiles the subset of supported C to the necessary libgccjit code
>> would be
>> useful to have for this cases but also educative for learning how to
>> use the
>> library.
>
> I really like this idea.
>
> Code using this plugin is going to want e.g. to access fields of
> structs, globals, etc, so it needs a way to:
> (a) populate a gcc_jit_context with those entities from the parsed C,
> (b) have a way for client code to get at those entities.
>
> As a concrete use-case, I attempted to use libgccjit to write a JIT-
> compiler for CPython, and found myself writing tedious error-prone code
> by hand to express the <Python.h> header:
> https://github.com/davidmalcolm/coconut/blob/master/coconut/compiler.py
>
> (ugh!)
>
> This client code was written in Python, using the Python bindings to
> libgccjit, rather than directly using the <libgccjit.h> C API.
>
> So presumably the plugin ought to support writing out the
> representation in some simple serialized format, and have a way to get
> at it from the various languages that bind libgccjit.
>
> Or maybe it's simplest to start with getting at the reflected IR from
> C?  (I'm thinking aloud here)

I guess would is a good point to start with.

> [Ideally it would support parsing C++ also, but clearly that's some big
> feature-creep: I attempted to write a JIT for GNU Octave, which is
> implemented in C++, and ran into the same issue as above: lots of hand-
> written reflection of the classes and globals.   Probably best to focus
> on a plugin for the C frontend for now.]
>
>>
>> Would be this something that is upstreamable in some form?
>
> Maybe eventually, but given that libgccjit is part of gcc and thus has
> a one-year release cycle, it feels like something that would best be a
> 3rd-party project for now.
>
> Any takers?  (my day job is bug-fixing gcc 9 right now)
>
> Dave
>

Okay I'll try to put some mostly weekend time on it.
I'll come up with something and I'll let you guys know.
Feel free if you have suggestions.

Bests

  Andrea

--
akrl@sdf.org