July 2024 - jextract-dev

prototypeless function representation
by Stephen Buergler 31 Jul '24

31 Jul '24

Hello! I think most of the time there is something like extern void RcloneInitialize(); is put into a header file it's meant to declare a function with no parameters. jextract outputs variadic versions of the binding though because that's not what that means. It means that the function declaration has no prototype and has an unknown number of parameters. extern void RcloneInitialize(void); This defines a function with no parameters and is what is usually intended and with this version the jextract bindings now reflect that there are no parameters to pass in. Would it make sense to change jextract to be able to treat these as functions that take no parameters? Alternatively, would it make sense to provide bindings for both versions of the function? If a `public static void RcloneInitialize()` and the variadic version existed I think that would make sense.

2 4

RFR: 7903782: clang warnings and diagnostics below warning level should be logged as well
by Athijegannathan Sundararajan 26 Jul '24

26 Jul '24

Parser logs clang warnings and diagnostics below warning level as well. ------------- Commit messages: - 7903782: clang warnings and diagnostics below warning level should be logged as well Changes: https://git.openjdk.org/jextract/pull/255/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=255&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903782 Stats: 14 lines in 2 files changed: 9 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jextract/pull/255.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/255/head:pull/255 PR: https://git.openjdk.org/jextract/pull/255

2 7

RFR: 7903779: unify logger messages to show position whenever possible
by Athijegannathan Sundararajan 25 Jul '24

25 Jul '24

* logger.warn/.err/.info Position accepting overloads. * Error message format is: <position>:"fatal"|"error"|"warning"|"info"|:<message> (consistent with clang). * ClangException has position, severity and spelling. ClangExceptions are printed using logger.print. ------------- Commit messages: - 7903779: unify logger messages to show position whenever possible Changes: https://git.openjdk.org/jextract/pull/254/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=254&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903779 Stats: 95 lines in 10 files changed: 65 ins; 3 del; 27 mod Patch: https://git.openjdk.org/jextract/pull/254.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/254/head:pull/254 PR: https://git.openjdk.org/jextract/pull/254

3 6

type Void is not supported
by Adrian Trapletti 22 Jul '24

22 Jul '24

Hi, I am trying to generate bindings for https://github.com/oxfordcontrol/Clarabel.cpp/blob/main/include/Clarabel.h Jextract issues the following warnings WARNING: Skipping ClarabelDefaultSolver_f64 (type Void is not supported) WARNING: Skipping ClarabelDefaultSolver_f32 (type Void is not supported) WARNING: Skipping ClarabelDefaultSolver (type Void is not supported) For me it seems that the returned void pointer is not supported https://github.com/oxfordcontrol/Clarabel.cpp/blob/main/include/c/DefaultSo… Is this a known issue? Is there a workaround? Thank you and best regards Adrian *Dr. Adrian Trapletti* CEO *Uster Metrics GmbH *| Steinstrasse 9b, 8610 Uster, Switzerland P +41 32 512 83 63 | M +41 79 103 71 31 a.trapletti(a)ustermetrics.com | www.ustermetrics.com This email message including any attachments is confidential and may be privileged. It is intended solely for the use of the individual or entity named on this message. It is provided for informational purposes only and does not constitute an offer or invitation to subscribe for or purchase any services or products. Any form of disclosure, copying, modification or distribution is unauthorized. If you are not the intended recipient, you are requested to please notify the sender immediately and delete the message including any attachments from your computer system network. Email transmission cannot be guaranteed to be secure or error free as information could be modified. We therefore do not accept responsibility or liability as to the completeness or accuracy of the information contained in this message or any attachments.

3 7

Re: [External] : Re: OSX in6_addr no longer generates compilable code after commit aa5f250
by Jorn Vernee 18 Jul '24

18 Jul '24

Jextract binaries are published at [1]. Those target the Java 22 FFM API. If you're on x64 mac, I believe the LLVM 'clang+llvm-13.0.1-x86_64-apple-darwin.tar.xz' package on the page you linked to should work. > I still have to manually change the gradle version each time due to Java 21, and then later Java 22. The current Gradle version should work if you run gradle with Java 17 on the PATH, and in JAVA_HOME. The JDK with which jextract is built is picked up through the `jdk22_home` project property instead. Jorn [1]: https://jdk.java.net/jextract/ On 17-7-2024 18:09, Alison Gravley wrote: > Yes, as I had no idea there were binaries anywhere. At least not on > github or for darwin. I have been using this LLVM version from > homebrew as everything had been "working" up until the change in > January. I vaguely remember having a really hard time getting jextract > to compile until I used the one from homebrew, but that was way back > in October. I still have to manually change the gradle version each > time due to Java 21, and then later Java 22. > > I am pretty sure the version updated recently when I ran some updates, > but I was running some version of 17 originally. > > Homebrew clang version 18.1.8 > Target: arm64-apple-darwin23.5.0 > Thread model: posix > InstalledDir: /opt/homebrew/opt/llvm/bin > > I can try the binary from here and try to get jextract to compile > again, but this may take me some time if I run into compiler issues. > https://github.com/llvm/llvm-project/releases/tag/llvmorg-13.0.1 > <https://urldefense.com/v3/__https://github.com/llvm/llvm-project/releases/t…> > > On Wed, Jul 17, 2024 at 11:15 AM Jorn Vernee <jorn.vernee(a)oracle.com> > wrote: > > Hey, > > Are you building jextract yourself? Note that only LLVM version 13 > works, as the naming of unnamed structs and unions in later > versions leads to these weird struct names. > > See also: https://bugs.openjdk.org/browse/CODETOOLS-7903480 > > Jorn > > On 17-7-2024 17:09, Alison Gravley wrote: >> I meant to send this months ago, but after commit >> aa5f25003554dffa18289f1be535ea23f75c29c3, which is from January >> 18, 2024, I can no longer use this tool on OSX (Arm) as the >> generated wrapper for in6 is invalid and cannot compile. I think >> the commit after this one is where the "--source" flag was removed. >> >> Basically, there are "unnamed at >> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/netinet6/in6.h:153:2" >> within the generated java that does not allow it to compile. >> >> I am not able to share the 3rd party library that I am using >> jextract on due to licensing, but in.h is from the OS. I am >> assuming this is being generated due to the library including these: >> >> ``` >> #include <signal.h> >> #include <sys/socket.h> >> #include <arpa/inet.h> >> #include <netinet/tcp.h> >> #include <netinet/in.h> >> #include <netdb.h> >> ``` >> >> Back in January, the generated in6_addr.java looked like this: >> >> ``` >> import java.lang.invoke.MethodHandle; >> import java.lang.invoke.VarHandle; >> import java.nio.ByteOrder; >> import java.lang.foreign.*; >> import static java.lang.foreign.ValueLayout.*; >> /** >> * {@snippet : >> * struct in6_addr { >> * union __u6_addr; >> * }; >> * } >> */ >> public class in6_addr { >> >> public static MemoryLayout $LAYOUT() { >> return constants$41.const$0; >> } >> /** >> * {@snippet : >> * union { >> * unsigned char __u6_addr8[16]; >> * unsigned short __u6_addr16[8]; >> * unsigned int __u6_addr32[4]; >> * }; >> * } >> */ >> public static final class __u6_addr { >> >> // Suppresses default constructor, ensuring >> non-instantiability. >> private __u6_addr() {} >> public static MemoryLayout $LAYOUT() { >> return constants$41.const$1; >> } >> public static MemorySegment >> __u6_addr8$slice(MemorySegment seg) { >> return seg.asSlice(0, 16); >> } >> public static MemorySegment >> __u6_addr16$slice(MemorySegment seg) { >> return seg.asSlice(0, 16); >> } >> public static MemorySegment >> __u6_addr32$slice(MemorySegment seg) { >> return seg.asSlice(0, 16); >> } >> public static long sizeof() { return $LAYOUT().byteSize(); } >> public static MemorySegment allocate(SegmentAllocator >> allocator) { return allocator.allocate($LAYOUT()); } >> public static MemorySegment allocateArray(long len, >> SegmentAllocator allocator) { >> return >> allocator.allocate(MemoryLayout.sequenceLayout(len, $LAYOUT())); >> } >> public static MemorySegment ofAddress(MemorySegment addr, >> Arena scope) { return RuntimeHelper.asArray(addr, $LAYOUT(), 1, >> scope); } >> } >> >> public static MemorySegment __u6_addr$slice(MemorySegment seg) { >> return seg.asSlice(0, 16); >> } >> public static long sizeof() { return $LAYOUT().byteSize(); } >> public static MemorySegment allocate(SegmentAllocator >> allocator) { return allocator.allocate($LAYOUT()); } >> public static MemorySegment allocateArray(long len, >> SegmentAllocator allocator) { >> return >> allocator.allocate(MemoryLayout.sequenceLayout(len, $LAYOUT())); >> } >> public static MemorySegment ofAddress(MemorySegment addr, >> Arena scope) { return RuntimeHelper.asArray(addr, $LAYOUT(), 1, >> scope); } >> } >> ``` >> >> Now I get lines like this in the generated java. I attached the >> full version: >> private static final GroupLayout $LAYOUT = MemoryLayout.structLayout( >> in6_addr.union (unnamed at >> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/netinet6/in6.h:153:2).layout().withName("__u6_addr") >> ).withName("in6_addr"); >> >>

2 1

OSX in6_addr no longer generates compilable code after commit aa5f250
by Alison Gravley 17 Jul '24

17 Jul '24

I meant to send this months ago, but after commit aa5f25003554dffa18289f1be535ea23f75c29c3, which is from January 18, 2024, I can no longer use this tool on OSX (Arm) as the generated wrapper for in6 is invalid and cannot compile. I think the commit after this one is where the "--source" flag was removed. Basically, there are "unnamed at /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/netinet6/in6.h:153:2" within the generated java that does not allow it to compile. I am not able to share the 3rd party library that I am using jextract on due to licensing, but in.h is from the OS. I am assuming this is being generated due to the library including these: ``` #include <signal.h> #include <sys/socket.h> #include <arpa/inet.h> #include <netinet/tcp.h> #include <netinet/in.h> #include <netdb.h> ``` Back in January, the generated in6_addr.java looked like this: ``` import java.lang.invoke.MethodHandle; import java.lang.invoke.VarHandle; import java.nio.ByteOrder; import java.lang.foreign.*; import static java.lang.foreign.ValueLayout.*; /** * {@snippet : * struct in6_addr { * union __u6_addr; * }; * } */ public class in6_addr { public static MemoryLayout $LAYOUT() { return constants$41.const$0; } /** * {@snippet : * union { * unsigned char __u6_addr8[16]; * unsigned short __u6_addr16[8]; * unsigned int __u6_addr32[4]; * }; * } */ public static final class __u6_addr { // Suppresses default constructor, ensuring non-instantiability. private __u6_addr() {} public static MemoryLayout $LAYOUT() { return constants$41.const$1; } public static MemorySegment __u6_addr8$slice(MemorySegment seg) { return seg.asSlice(0, 16); } public static MemorySegment __u6_addr16$slice(MemorySegment seg) { return seg.asSlice(0, 16); } public static MemorySegment __u6_addr32$slice(MemorySegment seg) { return seg.asSlice(0, 16); } public static long sizeof() { return $LAYOUT().byteSize(); } public static MemorySegment allocate(SegmentAllocator allocator) { return allocator.allocate($LAYOUT()); } public static MemorySegment allocateArray(long len, SegmentAllocator allocator) { return allocator.allocate(MemoryLayout.sequenceLayout(len, $LAYOUT())); } public static MemorySegment ofAddress(MemorySegment addr, Arena scope) { return RuntimeHelper.asArray(addr, $LAYOUT(), 1, scope); } } public static MemorySegment __u6_addr$slice(MemorySegment seg) { return seg.asSlice(0, 16); } public static long sizeof() { return $LAYOUT().byteSize(); } public static MemorySegment allocate(SegmentAllocator allocator) { return allocator.allocate($LAYOUT()); } public static MemorySegment allocateArray(long len, SegmentAllocator allocator) { return allocator.allocate(MemoryLayout.sequenceLayout(len, $LAYOUT())); } public static MemorySegment ofAddress(MemorySegment addr, Arena scope) { return RuntimeHelper.asArray(addr, $LAYOUT(), 1, scope); } } ``` Now I get lines like this in the generated java. I attached the full version: private static final GroupLayout $LAYOUT = MemoryLayout.structLayout( in6_addr.union (unnamed at /Library/Developer/CommandLineTools/SDKs/ MacOSX14.sdk/usr/include/netinet6/in6.h:153:2).layout() .withName("__u6_addr") ).withName("in6_addr");

2 1

RFR: 7903776: jextract generates uncompilable code when C identifier with the name from "java.lang" classes is used
by Athijegannathan Sundararajan 17 Jul '24

17 Jul '24

Unqualified names are mangled by NameMangler. But it was complete (didn't include "Boolean"). For uniformity & future proof mangling all type names from "java.lang" package. ------------- Commit messages: - 7903776: jextract generates uncompilable code when C identifier with the name from "java.lang" classes is used Changes: https://git.openjdk.org/jextract/pull/253/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=253&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903776 Stats: 95 lines in 3 files changed: 94 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/253.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/253/head:pull/253 PR: https://git.openjdk.org/jextract/pull/253

3 8

RFR: 7903777: jextract layout for enum with big constant values is wrong
by Maurizio Cimadamore 16 Jul '24

16 Jul '24

This PR fixes the code that generates enum layouts. Currently, the layout of an enum type is determined by looking at the type of the first enum constant. In some platforms, this strategy does not work, as an enum can have constants of **different** types. The solution is to ask clang what the integral type of the enum declaration is, and store that as an attribute in the enum declaration. Then, we should simply retrieve that type when generating layouts that depend on the enum. I've added a platform-dependent test, since this functionality is only really available on Linux/gcc (on Windows, enum constants are all truncated to 32 bits, it seems). ------------- Commit messages: - Remove tabs - Add test - Initial push Changes: https://git.openjdk.org/jextract/pull/252/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=252&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903777 Stats: 94 lines in 6 files changed: 81 ins; 6 del; 7 mod Patch: https://git.openjdk.org/jextract/pull/252.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/252/head:pull/252 PR: https://git.openjdk.org/jextract/pull/252

2 6

Two bugs (missing padding in struct layout / shadowing of existing class names)
by rafaeldaetwyler 16 Jul '24

16 Jul '24

Hi, I didn't find an issue tracker, therefore I hope to reach out through the correct channel. I am using jextract for a project and stumbled upon two bugs recently. I narrowed them down to be reproducible using the two header files attached. To reproduce, run - on Linux: jextract <file>.h - on Windows: jextract.bat <file>.h on a x86-64 machine using Build 22-jextract+5-33. *1. Struct generation (struct.h)* This bug occurs only on Linux. The layout which is generated for the struct (in structType.java) is comprised of a C_INT (for the enum) and C_LONG (for the uint64_t), without the necessary padding of 4 bytes after the C_INT. This results in a runtime error. Since the enum can take a value of both -1 and 0x80000000, an int32 is not enough to hold all values. Therefore, the layout should probably be C_LONG for the enum, too. On Windows, a padding is inserted after the C_INT layout. *2. Generation of variables with existing name (boolean.h)* When generating the code, the wrapper class Boolean is shadowed by the generated variable Boolean. The code doesn't compile because the line "static final boolean TRACE_DOWNCALLS = Boolean.getBoolean("jextract.trace.downcalls");" is interpreted as an illegal forward reference. This problem probably applies to all class names in java.lang, as those are automatically imported. It could be solved by applying a suffix to those names. One might argue that variables shouldn't be named like this in the first place, but when using an external library, variable names are already given and would need to be renamed manually. Best, Rafael

3 2