Getting "UnsatisfiedLinkError" in io_uring for methods that were defined as "static inline" in the header

[Gavin Ray]

Okay, it seems I've gotten the "hello world" almost working

The only problem left is that trying to read the "user_data" pointer
returned gives garbage.
When I submit the event, I attach a struct to it, like this:

        MemorySegment myStruct =
MemorySegment.allocateNative(myStructLayout, session);
        myStruct$foo.set(myStruct, 1);
        myStruct$bar.set(myStruct, 2);
        io_uring_sqe_set_data(sqePtr, myStruct);

Then when the results come back, I am doing this to read the userdata
pointer:

        MemorySegment cqes = io_uring_cqe.allocateArray(1, allocator);
        io_uring_wait_cqe(ring, cqes);
        // cqes[0]
        MemorySegment cqe = cqes.asSlice(0,
io_uring_cqe.$LAYOUT().byteSize());
        // cqes[0]->user_data
        MemoryAddress user_data =
MemoryAddress.ofLong(io_uring_cqe.user_data$get(cqe));
        MemorySegment user_data_segment =
MemorySegment.ofAddress(user_data, myStructLayout.byteSize(), session);

I try to print it out, comparing the "foo" and "bar" field against the
original values of "1" and "2"

        user_data->foo=1480561120
        user_data->bar=32545

Does anyone know/see what I am doing wrong here? 🤔
https://gist.github.com/GavinRay97/8ea0997693c00f8df61968a98ba30135#file-io_uring-java-L48-L55

On Wed, Sep 21, 2022 at 8:18 PM Gavin Ray <ray.gavin97 at gmail.com> wrote:

> @Daniel, I didn't know the lwjgl folks were looking into this area, I've
> had a brief look but it's definitely something I want to check out more!
>
> @Maurizio, the idea about defining a second library that depends on it is
> pretty clever.
>
> It turns out that you can pull liburing in with CMake without so much
> effort
> To set that scenario up was just the below code, this should work
> decently 👍
>
> =============================
> ExternalProject_Add(
>         liburing_git
>         GIT_REPOSITORY http://github.com/axboe/liburing.git
>         GIT_TAG liburing-2.2
>         BUILD_IN_SOURCE 1
>         BUILD_BYPRODUCTS "<SOURCE_DIR>/src/liburing.a"
>         BUILD_COMMAND make
> )
> ExternalProject_Get_Property(liburing_git SOURCE_DIR)
> add_library(liburing INTERFACE)
> add_dependencies(liburing liburing_git)
> target_include_directories(liburing INTERFACE ${SOURCE_DIR}/src/include)
> target_link_libraries(liburing INTERFACE ${SOURCE_DIR}/src/liburing.a)
>
> # NOW LINK IT TO SECOND LIBRARY
> add_library(liburing_extras SHARED liburing_extras/main.c)
> target_link_libraries(liburing_extras liburing)
> add_dependencies(liburing_extras liburing)
>
>
> On Wed, Sep 21, 2022 at 7:24 PM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>>
>> On 21/09/2022 23:39, Gavin Ray wrote:
>> > That makes sense -- I will look at patching liburing with a dirty
>> > one-liner that strips "static inline" from the definitions that have
>> > them then, ty =)
>>
>> Sorry, hit send too fast, and forgot to reply to this.
>>
>> There are few approaches that can be tried.
>>
>> First, you could define another shared library that depends on io_uring
>> - e.g. a C file which includes the io_uring header. This new file would
>> contain _new_ exported symbols for all the static inline functions,
>> whose implementation just delegates to the underlying static inline
>> functions (in the included io_uring header). Then you load up the
>> library with Panama and, if you have set up things correctly, you will
>> see both the static inlines and the exported symbols in IO uring. (in
>> fact, we do a similar trick to expose system library symbols like
>> "printf" on Windows, which implements them as macros).
>>
>> Another (more fun?) option would be to just keep the original library,
>> and implement the static inline functions in Java directly, using the
>> FFM API. Most of the functions I see have only 2-3 lines in them, so it
>> shouldn't be hard.
>>
>> Maurizio
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220923/f0e165d7/attachment.htm>