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

[Jorn Vernee]

On Mon, 16 Nov 2020 14:22:39 GMT, Magnus Ihse Bursie <ihse 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?

@magicus I think it's just a consequence of how the C ABI works on each platform. Without name mangling, there is no way to discern a function `void foo(int)` from another function `void foo(double)`.

C spec says this:

> All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined.

I.e. I can have a compilation unit that forward declares `extern void foo(int);` and then calls it, passing an `int` as argument. This gets compiled into a .obj file that just has e.g. an external `_foo` in it's symbol table, i.e. no type information included. Then another compilation unit that define a `void foo(double)`. Again .obj file will just have a `_foo` symbol in it. Linker is happy to link the 2 together, but the behavior is undefined.'

Maybe there is something that the linker can do based on other information in the .obj file, but guess it doesn't? (Or maybe we don't turn it on)

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

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