[foreign-jextract] Function pointer typedef name clashes with existing function name

Filip Krakowski krakowski at hhu.de
Wed Feb 24 07:30:17 UTC 2021


Hi Maurizio,

sorry for taking so long to reply.

Yes, I can confirm that it is now working without having to specify 
filters anymore. Thank you! :)

Filip

On 2/16/21 11:52 AM, Maurizio Cimadamore wrote:
> Hi Filip,
> it occurred to me that the push we did yesterday of the new source
> generation scheme should help somehow mitigating the issue you found -
> would you mind giving it a try?
>
> That said, it only reduces the chances of the problem happening, and
> we'll need to work on a fuller fix.
>
> Thanks
> Maurizio
>
>
>
> On Wed, 2021-02-10 at 15:46 +0100, Filip Krakowski wrote:
>> Hi,
>>
>> thanks for filing the issue! I found that I can use the "--filter"
>> flag
>> to exclude ucx's
>> header containing the function pointer (since it doesn't contain any
>> symbols I use at the moment).
>>
>> I will use this method as a workaround for now.
>>
>> Filip
>>
>> On 2/10/21 3:20 PM, Maurizio Cimadamore wrote:
>>> Hi Filip,
>>> thanks for the report - I've filed this:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8261511
>>>
>>> I believe jextract adds constants to the constant holder
>>> sources/classes on a name-based basis. So if you happen to have two
>>> descriptors that are required for different things (e.g. a function
>>> and
>>> an upcall which happen to have same name), there is a chance that
>>> one
>>> constant will be re-used for the other.
>>>
>>> The solution is, of course, to use a more robust keying scheme when
>>> adding constants, rather than just using the name.
>>>
>>> Maurizio
>>>
>>> On Wed, 2021-02-10 at 15:05 +0100, Filip Krakowski wrote:
>>>> Hi,
>>>>
>>>> I think I found another bug regarding name clashes with typedefs
>>>> for
>>>> function pointers.
>>>>
>>>> The library I use declares a function pointer within a struct's
>>>> field
>>>> named "read" [1]. I think you see where this is going...
>>>>
>>>>       typedef struct ucs_config_parser {
>>>>            int                      (*read) (const char *buf, void
>>>> *dest,
>>>>       const void *arg);
>>>>            int                      (*write)(char *buf, size_t
>>>> max,
>>>>                                              const void *src,
>>>> const
>>>> void
>>>>       *arg);
>>>>            ucs_status_t             (*clone)(const void *src, void
>>>> *dest,
>>>>       const void *arg);
>>>>            void                     (*release)(void *ptr, const
>>>> void
>>>> *arg);
>>>>            void                     (*help)(char *buf, size_t max,
>>>> const
>>>>       void *arg);
>>>>            const void               *arg;
>>>>       } ucs_config_parser_t;
>>>>
>>>>
>>>> Since "unistd.h" also declares a "read" function [2], jextract
>>>> then
>>>> (correctly) generates a MethodHandle for it
>>>> but uses the wrong FunctionDescriptor belonging to ucx's "read"
>>>> in
>>>> the
>>>> process.
>>>>
>>>>       static final FunctionDescriptor read$FUNC_ =
>>>>       FunctionDescriptor.of(C_INT,
>>>>                C_POINTER,
>>>>                C_POINTER,
>>>>                C_POINTER
>>>>       );
>>>>
>>>>       static final MethodHandle read$MH_ =
>>>> RuntimeHelper.downcallHandle(
>>>>                LIBRARIES, "read",
>>>>                "(ILjdk/incubator/foreign/MemoryAddress;J)J",
>>>>                read$FUNC_, false
>>>>       );
>>>>
>>>>
>>>> As you can see the generated FunctionDescriptor and the
>>>> descriptor
>>>> string ("(ILjdk/incubator/foreign/MemoryAddress;J)J")
>>>> do not match. On startup, I immediately get the following
>>>> Exception
>>>> originating from the downcallHandle call.
>>>>
>>>>       Caused by: java.lang.IllegalArgumentException: Carrier size
>>>>       mismatch: int != b64[abi/kind=POINTER]
>>>>
>>>> My guess is that the FunctionDescriptor is generated correctly at
>>>> first,
>>>> but gets overridden once the parser reaches the
>>>> function pointer declared within the struct in [1].
>>>>
>>>>
>>>> Best regards
>>>> Filip
>>>>
>>>> [1]
>>>> https://urldefense.com/v3/__https://github.com/openucx/ucx/blob/16ad2cc56b6c63a0fdc39bac3dce03463d6d137f/src/ucs/config/parser.h*L40-L48__;Iw!!GqivPVa7Brio!KEo92XLsYKALhHhpdKLdJmnGbBeEBzWzNrwVGsMfUzPtmXaTTTmsk7KgBzYKtKhTuq5_prU$
>>>> [2]
>>>> https://urldefense.com/v3/__https://linux.die.net/man/2/read__;!!GqivPVa7Brio!KEo92XLsYKALhHhpdKLdJmnGbBeEBzWzNrwVGsMfUzPtmXaTTTmsk7KgBzYKtKhTTMv6teo$
>>>>   



More information about the panama-dev mailing list