Provide API points for implementing linkers with non-standard calling conventions

[Владимир Козелков]

Greetings,

The documentation for the Linker.nativeLinker() method says: "It is not
currently possible to obtain a linker for a different combination of OS and
processor."

This is indeed true for hotspot, but what if another implementation could
provide the ability to create a linker for a different calling convention?
Even if the implementation wanted to do this, it would fail because the API
does not provide any points through which this could be done.

As an example - android allows us to use binaries for arm in aarch64 and
for x86 in x86_64 with JNI. In the current implementation, I have to filter
the output of SymbolLookup.loaderLookup() so that the user does not get
symbols with a different calling convention, although the platform really
allows to use them.

Additionally, I would like to note that the x86 and x86_64 platforms have
several "native" calling conventions, such as cdecl (which is actually used
now), fastcall, vectorcall, etc. Even if a hotspot does not allow these
calling conventions, it would be useful to have at least the potential to
implement them.

I can suggest a not very good and naive method for solving the problem - it
is inspired by target-triple from LLVM:

interface Linker ... {
    static List<String> supportedConventions() {return ... ;}
    static String defaultConvention() {return ... ;}
    static boolean isSupportedConvention(String  convention) {return ... ;}
    static Linker linkerForConvention(String  convention) {return ... ;}
    static Linker nativeLinker() {
        return linkerForConvention(defaultConvention());
    }
}

For android aarch64 defaultConvention() will return something like
"aarch64-android-cdecl"

Thanks for reading
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20241011/fa9be1b6/attachment-0001.htm>