jextract C++ support

[Maurizio Cimadamore]

Hi
I'd describe more C++ as a sort of ongoing exploration at the moment 
(but, our priorities lie in the finalization of the FFM API).

Adding some basic support for it is doable - name mangling isn't (as 
Manuel says) the biggest concern - after all, libclang gives us all the 
correct mangled name, so it's easy to generate a downcall method handle 
targeting a mangled symbol name, but expose it as a "nice-looking" 
source-like name.

A very basic PoC which adds some C++ support can be found here [1]. This 
is the result of half a day of hacking on the jextract code, so it is by 
no means complete. I'm sharing it here mostly for "educational 
purposes", so that I can talk about what I learned from it :-) While "it 
works", as noted, there are many things that leave to be desired:

* templates do not work correctly
* dynamic dispatch is not supported
* everything that is "inline" doesn't work
* (probably way more stuff, like exceptions, etc.)

Some (all?) these limitations are shared across all the tools which 
share a similar approach - e.g. Rust's bindgen [2].

My personal feeling is that C++ is too much of a stretch for an approach 
that targets C++ directly (as done in my patch). As John has noted in 
this document [3], adding "decent" support for C++ would require 
jextract to generate a shim library on the side, which would help Java 
clients perform complex C++ operations which either rely on the 
compiler, or the runtime (or both).

There might be more than one way to emit this shim library - one would 
be to actually compile it and then add a dependency on it from the 
generated binidngs (that's the JavaCPP [4] approach). Another approach 
could be to embed compiled code, in some way, directly into the bindings 
themselves - then at runtime turn the compiled code into a memory 
segment, and make it executable. That seems more complex, and I'm not 
sure if worth it (but wanted to list the option for completeness). In 
that spirit, I also note how there exist some macro assembler options 
written using FFM API [5] which might (or not!) play a role in the 
translation strategy. Again, mostly jotting some thoughts.

No matter which approach is chosen, I think one of the first problem 
which would need to address is some way to "lower" a C++ library into 
plain C, so as to automate the generation of this shim library (which we 
can then link against using FFM API). And, while there have been many 
experiments in this area over the years, I didn't come across anything 
that seemed "up to date", or directly usable from us. So perhaps I'd 
suggest to start from there? Note that that could even be a separate 
tool (which then you run jextract against, as usual).

[1] - 
https://github.com/openjdk/jextract/compare/panama...mcimadamore:jextract:cxx?expand=1
[2] - https://rust-lang.github.io/rust-bindgen/cpp.html
[3] - https://cr.openjdk.org/~jrose/panama/cppapi.cpp.txt
[4] - https://github.com/bytedeco/javacpp
[5] - https://github.com/YaSuenag/ffmasm



On 15/05/2023 02:25, Rel wrote:

> Hi,
>
> I would like to know how to participate in C++ support for jextract.
> Watching Project Panama video 
> (https://inside.java/2023/04/18/levelup-panama/), Paul mentioned that 
> C++ is in the plans.
> Do we have someone working on it already so I can syncup on what is 
> the plan and where I can help?
> In particular:
> - will it be part of jextract or may be jextract++?
> - will it use clang or something else? if clang then which interface 
> https://clang.llvm.org/docs/Tooling.html
>
> There are many things to be done for C++ support but if I pick the 
> most basic like symbols, in C++ they are mangled so current jextract 
> linking logic will need to be changed. Do you think modifying 
> NameMangler to store those mangled C++ symbols will be the right approach?
>
> Regards,