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

Magnus Ihse Bursie ihse at openjdk.java.net
Mon Nov 16 15:08:59 UTC 2020


On Mon, 16 Nov 2020 14:57:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>>> @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 :) )

@JornVernee Yes, it was something like that I was after. If the header file is always included, we get a compiler error if the declaration and definition differ.

There is actually compiler flags that enforce this; basically saying that a symbol must either be declared before being defined (that is, have the header included), or it must not be exported outside the object file. Some month ago I tried enabling it on hotspot, but it generated too many warnings at that point for me to handle them; for that to work we'd need to do some passes over the code and make sure that these conditions are fulfilled.

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

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


More information about the hotspot-dev mailing list