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

[Jorn Vernee]

On Mon, 16 Nov 2020 14:49:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Looks good.
>> 
>> Interesting. So because we export with extern "C" all other platforms had the name decorations stripped away, and we only notice the mismatch because 32bit windows still has calling convention specific decorations.
>> 
>> ..Thomas
>
>> @tstuefe This is a but unnerving. I have no objections to the patch, but it seems worrisome that this mismatch was not caught on other platforms. Anyone care digging more deeply into why this is the case?
> 
> I guess the price you pay for extern-"C"-ing the `JVM_xxx()` entry points? Leaves the symbols C++-undecorated. Which makes sense, of course, since outside code wants to dynamically resolve those symbols.
> 
> On 32bit Windows we have a second decoration scheme, nothing to do with C++, depending on the calling convention. 32bit Windows has three of those, no other platform has that. The JVM_xx() use JNICALL which is "__stdcall" which causes the name to have a leading underscore and followed by '@' + the number bytes in the argument list. Since the new argument list of the prototype had a different number of arguments than the implementation, this led to a different number after the @.
> 
> I guess there is not much you can do here. On other platforms, a caller would have loaded the symbol by name and called it with the wrong number of arguments, which then hopefully causes crashes? Not sure how to prevent this. Apart from maybe macro-fying the argument list somewhere central or similar techniques.

Hmm, just realized we could help the situation by including the header file (with the forward declaration) from the file that has the definition. Compiler will then complain about a conflicting declaration of the function. 

(time to write a script that catches files which don't do this :) )

-------------

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