RFR: [panama foreign] Build tweak to enable build on Windows

Mon Oct 29 13:03:39 UTC 2018

Thanks Henry, the files are now copied over as expected :)

Just now I was also looking at the way you're solving the problem of 
missing `alloca` in `jdk_internal_clang.cpp`, which I've ran into myself 
in other places.

I see you've switched to calloc, but you're not freeing the pointer it 
creates, so this is a memory leak (this problem doesn't exist with 
alloca since it allocates space on the stack). You can put 
`free(filteredTokens);` after the `out:` label to ensure that it gets 
freed in the case of an exception as well.

I remember seeing some talk recently about bumping up the C/C++ standard 
the JDK operates on, so soon we could hopefully use C99 variable length 
arrays and this won't be a problem :)

I'm currently using the C++ version of alloca (called _alloca) using 
this macro:

#ifdef _WIN64
#include <malloc.h>
#define alloca _alloca
#endif

Which also seems to work.

---

I'm also looking at /hotspot/cpu/x86/directUpcallHandler_x86.cpp

You're putting `mask` and `rec_adr` into rdi and rsi, but those or not 
argument registers on MSx64 [1], so this won't work.

The direct invoker doesn't work for Windows currently since it can't 
handle the argument shuffling and it uses a different number of 
registers, so I've also put in that compiler switch, but left the 
Windows branch with a FIXME, since there's no real quick-fix.

Picking which invoker is used is done by the binder code, so on Windows 
it will just choose not to use the direct invoker at all for now.

Cheers,
Jorn

[1] : 
https://docs.microsoft.com/en-us/cpp/build/parameter-passing?view=vs-2017

Henry Jen schreef op 2018-10-29 06:55:
> Updated webrev[1] fix the link issue and revert CXX CXXCPP as suggested 
> by Erik.
> 
> [1] 
> https://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev.01/webrev/
> 
> Cheers,
> Henry
> 
> 
>> On Oct 28, 2018, at 9:11 AM, Henry Jen <henry.jen at oracle.com> wrote:
>> 
>> I think the is caused by link under cygwin on Windows. I’ll double 
>> check and fix them.
>> 
>> Cheers,
>> Henry
>> 
>>> On Oct 28, 2018, at 6:04 AM, Jorn Vernee <jbvernee at xs4all.nl> wrote:
>>> 
>>> To add to this (and add missing CCs, sorry about that);
>>> 
>>> There are 3 libclang.dll files in the build output after running 
>>> `make clean images`;
>>> 
>>> images\jdk\bin\libclang.dll
>>> jdk\bin\libclang.dll
>>> support\modules_libs\jdk.internal.clang\libclang.dll
>>> 
>>> All of these files are only 80 bytes in size, while they are supposed 
>>> to be 57+ MB. So I think definitely something is going wrong with the 
>>> copy. I can't find the build system code that does the copying 
>>> though, so I'm not sure how to debug this.
>>> 
>>> AFAIK we are not building the library from scratch on Windows right? 
>>> Just copying over the .dll from the pre-built distribution?
>>> 
>>> Jorn
>>> 
>>> Jorn Vernee schreef op 2018-10-27 19:53:
>>>> Hi Henry,
>>>> I'm testing out this patch and can confirm jextract.exe is being
>>>> built, but I can't use it to extract a header file.
>>>> I'm getting an UnsatisfiedLinkError when loading jclang.dll:
>>>> ```
>>>> PS J:\WS\JNI test\C> jextract Main.h
>>>> Exception in thread "main" java.lang.UnsatisfiedLinkError:
>>>> J:\cygwin64\home\Jorn\cygwin-projects\panama\build\windows-x8
>>>> 6_64-server-release\images\jdk\bin\jclang.dll: %1 is not a valid 
>>>> Win32
>>>> application
>>>>       at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native 
>>>> Method)
>>>>       at
>>>> java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2462)
>>>>       at
>>>> java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2534)
>>>>       at 
>>>> java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2744)
>>>>       at 
>>>> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2690)
>>>>       at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:851)
>>>>       at java.base/java.lang.System.loadLibrary(System.java:1903)
>>>>       at
>>>> jdk.internal.clang/jdk.internal.clang.LibClang.<clinit>(LibClang.java:35)
>>>>       at
>>>> jdk.jextract/com.sun.tools.jextract.parser.Parser.parse(Parser.java:74)
>>>>       at 
>>>> jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:411)
>>>>       at 
>>>> jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:387)
>>>>       at jdk.jextract/com.sun.tools.jextract.Main.run(Main.java:251)
>>>>       at 
>>>> jdk.jextract/com.sun.tools.jextract.Main.main(Main.java:316)
>>>> ```
>>>> When inspecting jclang.dll with 'dependency walker' (a DLL 
>>>> inspection
>>>> tool [1]) it's giving an error about libclang.dll (a dependency of
>>>> jclang.dll), which tells me "No DOS or PE signature found. This file
>>>> is not a valid 32-bit or 64-bit Windows module.". However, when I 
>>>> open
>>>> the original libclang.dll file from my LLVM installation it _is_ 
>>>> being
>>>> recognized as a valid DLL.
>>>> I think something is going wrong when copying libclang.dll over? I
>>>> have tried manually copying over the libclang.dll file to the jclang
>>>> and jdk/bin folders, which allows me to extract a header file using
>>>> that command line, but when re-running the build the DLL is being
>>>> overwritten again with the corrupted/invalid version.
>>>> Cheers,
>>>> Jorn
>>>> [1] : http://www.dependencywalker.com/
>>>> Henry Jen schreef op 2018-10-26 06:44:
>>>>> Hi,
>>>>> Please review a web rev[1] that address following,
>>>>> 1. Copy the essential share library as recorded by the linker
>>>>> following the symbolic link of libclang.so for unix/mac. This leads 
>>>>> to
>>>>> only one copy of share library instead of a duplicate copy of
>>>>> libclang.so. It would be nice to have create libclang as a symbolic
>>>>> link, but it’s not needed now.
>>>>> This issue is what failed the build when using system provided
>>>>> libclang on some systems such as Debian-based Linux distribution.
>>>>> After this patch, Debian-based system can be build as described in
>>>>> README.foreign.
>>>>> 2. Enable build on Windows. This patch allow build image to be
>>>>> completed successfully and libclang.dll copied to bin as expected.
>>>>> However, this doesn’t mean binder is working on Windows, it’s 
>>>>> simply
>>>>> get the build going and jextract should be functional. Some test 
>>>>> still
>>>>> have compiling errors to be fixed, and we don’t have Windows ABI. 
>>>>> It’s
>>>>> the first step to allow build on Windows.
>>>>> I believe a lot of this had been addressed by Jorn, and he actually
>>>>> have made more progress on Windows support. Hopefully this is just 
>>>>> the
>>>>> first step and get Windows going.
>>>>> Cheers,
>>>>> Henry
>>>>> [1] 
>>>>> http://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev
>> 