[foreign] Running tests on Windows

[Jorn Vernee]

Henry Jen schreef op 2018-09-19 17:23:
> On Sep 19, 2018, at 5:00 AM, Jorn Vernee <jbvernee at xs4all.nl> wrote:
>> 
>> Hello guys,
>> 
>> I'm making good progress with getting things to work on windows and 
>> now have mixed arguments and float varargs working.
>> 
> 
> Nice, do you have a reference to Win32 ABI/calling convention?

Yeah, I'm using the same one Bob is, but the one for VS2017 [1], though 
I think that only covers x64, not 32 bit stuff. There are no more Oracle 
builds of 32bit jdks but I'm not sure what the OpenJDK consensus is for 
supporting 32 bits? It certainly makes things easier to only have to 
deal with 1 calling convention.

>> I'm currently running the jdk_foreign tests (of which 31 are being 
>> run) to see which ones are failing. I'm getting currently 14 out of 
>> 31.
>> 
>> One of the problems I'm running into is that the tests depend on POSIX 
>> functions, which are not in the C standard library on windows. The 
>> main culprit being getpid (although it is in the C++ standard library 
>> under the mangled name _getpid, but name mangling in C++ is 
>> non-portable either). I'm wondering how you'd like to handle these? I 
>> don't know if there is a way to make platform specific tests?
>> 
> 
> Use jtreg @requires tag, something like @requires (os.family == 
> "windows")

Thanks!

>> There is also a use of alloca, for which there is a replacement in 
>> C99, but I don't know which C and C++ standards the jdk is on? (iirc 
>> C++ was before std11, which is pretty old). I wanted to change alloca 
>> to using a variable sized array, but the compiler is rejecting that. 
>> (currently using _alloca to test with)
>> 
>> I was seeing the warning 'Not building java.foreign tests' coming from 
>> make/test/native/JtregNativeJdk.gmk, so I've added a filter and flags 
>> for windows as well. But, it doesn't look like these filter were doing 
>> anything in the first place, since `make test` was already outputting 
>> a bunch of dlls, just through some other path it seems. I'm seeing a 
>> lot of warnings like
>> 
>>    JtregNativeJdk.gmk:96: warning: ignoring old recipe for target 
>> '/cygdrive/j/cygwin64/home/Jorn/cygwin-projects/panama/build/windows-x86_64-normal-server-release/support/test/jdk/jtreg/native/lib/Hello.dll'
>> 
>> So I don't know if that filter is still relevant? What is it actually 
>> (supposed to be) doing?
>> 
>> Another thing with the native test files is that dlls require you to 
>> explicitly export symbols. There are 4 different ways to do this, 
>> either through a command line option, a side file, using a decorator 
>> `__declspec(dllexport)`, or using a #pragma comment. I wonder if there 
>> is an established way of doing that for tests that you know of?
>> 
> 
> We haven’t. But a common practice is use #ifdef to make a decoration
> portable, and that would serve as a test case for jextract as well. I
> would try to avoid mess with build system unless there is an
> established way to do what we needed.

That should work, I think I can just copy what JNI is doing with 
JNIEXPORT.

>> And then of course one of the biggest things is getting jextract to 
>> build and run. Currently the build system is not picking up libclang. 
>> When explicitly specifying it with --with-libclang='/cygdrive/j/LLVM' 
>> I still get the "Cannot locate libclang!" warning. I wanted to ask 
>> what value and files it's actually looking for? (I've also tried some 
>> of the additional flags from makeautoconf/lib-clang.m4, but to no 
>> avail).
>> 
> 
> —with-libclang should point to a directory has include/clang-c and
> lib/libclang.dll. If include and lib are not under the same directory,
> you can use —with-libclang-include and —with-libclang-lib instead.

I have tried all of these flags together:

--with-libclang=/cygdrive/j/LLVM 
--with-libclang-include=/cygdrive/j/LLVM/include 
--with-libclang-include-aux=/cygdrive/j/LLVM/lib 
--with-libclang-lib=/cygdrive/j/LLVM/bin

On windows the dll is under /bin, the lib folder just has an archive 
file (filled with symbols) [2]. There is a folder include/clang-c but it 
is just not being picked up. I'm seeing:

checking clang-c/Index.h usability... no
checking clang-c/Index.h presence... no
checking for clang-c/Index.h... no
configure: Cannot locate libclang! You can download pre-built llvm
         binary from http://llvm.org/releases/download.html, then specify 
the
         location using --with-libclang

Sorry, the build system is pretty opaque from my point of view, so I 
just don't know how to deal with this.

> HTH,
> Henry

Thanks,
Jorn

[1] : 
https://docs.microsoft.com/en-us/cpp/build/overview-of-x64-calling-conventions?view=vs-2017
[2] : 
https://gist.github.com/JornVernee/dae92a19f4d2036f30153e747b55d874