RFR: 8256380: JDK-8254162 broke 32bit windows build

[David Holmes]

Hi Jorn,

On 17/11/2020 8:33 pm, Jorn Vernee wrote:
> On Tue, 17 Nov 2020 01:58:03 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Fix win-32 linker error due to forward declaration and definition signature mismatch.
>>>
>>> FWIW, the altered header is included from nativeLookup.cpp, which uses the function pointer of that function. But, since the signature of the definition [1] is different, and due to name mangling on the particular ABI, the symbols of the declaration in the header and definition are different as well, and things fail to link later.
>>>
>>> Testing: Building Windows-x86 locally, and running jdk_foreign tests.
>>>
>>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/scopedMemoryAccess.cpp#L181
>>
>> src/hotspot/share/prims/scopedMemoryAccess.hpp line 32:
>>
>>> 30:
>>> 31: extern "C" {
>>> 32:   void JNICALL JVM_RegisterJDKInternalMiscScopedMemoryAccessMethods(JNIEnv *env, jclass scopedMemoryAccessClass);
>>
>> Why isn't this declared with JNIEXPORT like the functions in jvm.h?
> 
> It's similar to the declarations in nativeLookup.cpp. Those don't have JNIEXPORT either.
> 
> FWIW, this symbol doesn't need to/shouldn't be exported, since we only reference it internally as the implementation of a Java  registerNatives method, and it's not meant to be called directly when an external program links against libjvm.
> 
> The functions in jvm.h are part of an API though, so those need to be exported. e.g. on Windows the macro expands to __declspec(dllexport), which is used to make the symbol externally visible in the final jvm.dll.

All of jvm.h defines a contract between the JDK and JVM, not any 
external program. The JNIEXPORT is so that native code in libjava.so (or 
other JDK native libs) can call native code in libjvm.so. Possibly this 
is unneeded when the registration logic itself is executed in the VM.

Cheers,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1222
>