Re: How to build hotspot jtreg test JNI with specific CFLAGS?
Hi Severin, Can never remember if "make run-test" is the current or old way to run tests. What do you see if you run "make test-image"? David On 4/08/2018 12:19 AM, Severin Gehwolf wrote: Hi, I'm trying to get a JNI library used for testing to be compiled with certain CFLAGS. In particular, I'm trying to get it compiled on a GCC platform with '-fomit-frame-pointer' and/or '-fomit-frame-pointer -O3'. The patch currently looks like this: diff --git a/make/test/JtregNativeHotspot.gmk b/make/test/JtregNativeHotspot.gmk --- a/make/test/JtregNativeHotspot.gmk +++ b/make/test/JtregNativeHotspot.gmk @@ -139,6 +139,13 @@ -I$(VM_TESTBASE_DIR)/nsk/share/native \ -I$(VM_TESTBASE_DIR)/nsk/share/jni +NO_FRAMEPOINTER_CFLAGS := +ifeq ($(OPENJDK_TARGET_OS),linux) + NO_FRAMEPOINTER_CFLAGS := -O3 -fomit-frame-pointer +endif + +BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS_libNoFramePointer := $(NO_FRAMEPOINTER_CFLAGS) + BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS_libProcessUtils := $(VM_SHARE_INCLUDES) BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS_libThreadController := $(NSK_MONITORING_INCLUDES) When I look at the compile command line this produces with 'make run-test', I see this: $ cat ./build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/support/libNoFramePointer/libNoFramePointer.o.cmdline /usr/bin/gcc -I/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-normal-server-release/support/modules_include/java.base -I/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-normal-server-release/support/modules_include/java.base/linux -I/disk/openjdk/upstream-sources/openjdk-head/src/java.base/share/native/libjava -I/disk/openjdk/upstream-sources/openjdk-head/src/java.base/unix/native/libjava -I/disk/openjdk/upstream-sources/openjdk-head/src/hotspot/share/include -I/disk/openjdk/upstream-sources/openjdk-head/src/hotspot/os/posix/include -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -DLINUX -DNDEBUG -Wall -Wextra -Wno-unused -Wno-unused-parameter -Wformat=2 -fno-strict-aliasing -m64 -D_LITTLE_ENDIAN -DARCH='"amd64"' -Damd64 -D_LP64=1 -fno-omit-frame-pointer -fno-delete-null-pointer-checks -fno-lifetime-dse -fPIC -O3 -fomit-frame-pointer -g -O2 -DTHIS_FILE='""' -c -MMD -MF /disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/support/libNoFramePointer/libNoFramePointer.d -o /disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/support/libNoFramePointer/libNoFramePointer.o /disk/openjdk/upstream-sources/openjdk-head/test/hotspot/jtreg/serviceability/sa/libNoFramePointer.c The command line has '-O3 -fomit-frame-pointer -g -O2' in that order. This screws things up since -O2 seems to override -fomit-frame-pointer. My guess is that -O2 is from OPTIMIZATION == LOW, but not sure. How can I get this -O2 flag removed which apparently gets added later? Thanks, Severin
Re: System Reaction - Stunned
On 6/08/2018 5:57 AM, mr rupplin wrote: Hello. Trying to understand the "make process" as it relates to a fundamental build and where the files end up going. Not being pushy at all. Your subject line conveys a different sentiment. I'm having trouble locating the files after the "make" command executes. So quickly a few questions: 1. Where do the Standard Java (System.java, etc.) go when they are compiled (System.class)? You already found them - no magic or mystery here. The class file gets compiled into the appropriate directory. For JDK 9 and above, where we use the module system this is: /jdk/modules/java.base/java/lang/ When you create an actual JDK image these class files will then get incorporated into the module file e.g. /images/jdk/jmods/java.base.jmod 2. Where are the native mappings? How does this work? For instance System.c gets mapped to a .o but then what? kthx. Each native library has a set of source directories which are then compiled and linked together to form that library. The native sources for the core library classes, like System.c, are all part of libjava.so. David - I show some .class files under /jdk9/build/linux-x86_64-normal-server-release/jdk/modules/java.base however these are not apparently the direct process descendants of source files at jdk9/jdk/src/java.base/share/classes . I will be called on to answer these. Please consider looking and making the connections evident in the build process. The output println statements are not correct enough for even me to see, understand for that. ok. Thanks, Mr. Max Friend to Mankind
System Reaction - Stunned
Hello. Trying to understand the "make process" as it relates to a fundamental build and where the files end up going. Not being pushy at all. I'm having trouble locating the files after the "make" command executes. So quickly a few questions: 1. Where do the Standard Java (System.java, etc.) go when they are compiled (System.class)? 2. Where are the native mappings? How does this work? For instance System.c gets mapped to a .o but then what? kthx. I show some .class files under /jdk9/build/linux-x86_64-normal-server-release/jdk/modules/java.base however these are not apparently the direct process descendants of source files at jdk9/jdk/src/java.base/share/classes . I will be called on to answer these. Please consider looking and making the connections evident in the build process. The output println statements are not correct enough for even me to see, understand for that. ok. Thanks, Mr. Max Friend to Mankind
Re: 8202794: Native Unix code should use readdir rather than readdir_r
On 03/08/2018 20:26, t...@tedneward.com wrote: Hey, all; did this get resolved? I'm still getting this error in pulled-yesterday clones of jdk8u and jdk9 and jdk10. I would prefer not to make local changes (mostly I want to build debug builds so I can spelunk the JVM bits), but if this isn't going to roll out fairly shortly I'll disable warnings-as-errors and carry on. The changes for JDK-8202353, JDK-8202794, and JDK-8207340 are in jdk/jdk for JDK 12. There are few residual issues/inconsistencies that came up and are still under discussion on the mailing lists. I don't think there has been any discussion yet about back porting. -Alan
