[foreign] Running tests on Windows

Bob Vandette bob.vandette at oracle.com
Wed Sep 19 15:25:50 UTC 2018


> On Sep 19, 2018, at 11:23 AM, Henry Jen <henry.jen at oracle.com> wrote:
> 
> 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?

I used this as reference for the SVM Windows calling convention work I just completed.

https://msdn.microsoft.com/en-us/library/ms235286.aspx

Bob.

> 
>> 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")
> 
>> 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.
> 
>> 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.
> 
> HTH,
> Henry
> 



More information about the panama-dev mailing list