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

[Thomas Stuefe]

On Mon, 16 Nov 2020 12:36:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Looks good to me, and trivial.
>
> 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.

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

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