<div dir="ltr">Greetings,<div><br></div><div>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."</div><div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>I can suggest a not very good and naive method for solving the problem - it is inspired by target-triple from LLVM:<br></div><div><br></div><div>interface Linker ... {</div><div>    static List<String> supportedConventions() {return ... ;}<br></div><div>    static String defaultConvention() {return ... ;}</div><div>    static boolean isSupportedConvention(String  convention) {return ... ;}<br></div>    static Linker linkerForConvention(String  convention) {return ... ;}<div>    static Linker nativeLinker() {<br>        return linkerForConvention(defaultConvention());</div><div>    }<div>}</div><div><br></div><div>For android aarch64 defaultConvention() will return something like "aarch64-android-cdecl"</div><div><br></div></div></div><div>Thanks for reading<br></div></div>