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

[Maurizio Cimadamore]

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$
> > >