From tdaitx at br.ibm.com Wed Sep 3 21:00:21 2014 From: tdaitx at br.ibm.com (Tiago =?ISO-8859-1?Q?St=FCrmer?= Daitx) Date: Wed, 03 Sep 2014 18:00:21 -0300 Subject: JDK8u20 build failure [Was: OpenJDK9 build failure] In-Reply-To: References: <1403103138.3862.274.camel@ocdc.br.ibm.com> <1403720281.3862.336.camel@ocdc.br.ibm.com> <53AB8661.3080606@oracle.com> <1403757793.3862.344.camel@ocdc.br.ibm.com> <53ABC114.4080400@oracle.com> Message-ID: <1409778021.3937.20.camel@ocdc.br.ibm.com> On Thu, 2014-06-26 at 09:30 +0200, Volker Simonis wrote: > Hi David, Tiago, > > sorry for the daly, but I was on leave during the last two weeks. > > I already have a patch for the 'format specifier issue' and will post > a webrev later today. I hit the same issue Today on jdk8u20 from http://hg.openjdk.java.net/jdk8u/jdk8u20-dev/ By looking at bug I see it reports as affecting 8u40 and 9 (I failed to notice this before), is any fix expected for 8u20 or is it too late for that? Regards, Tiago > > @David: thanks for creating the bug! > > Regards, > Volker > > > On Thu, Jun 26, 2014 at 8:43 AM, David Holmes wrote: > > On 26/06/2014 2:43 PM, Tiago St?rmer Daitx wrote: > >> > >> On Thu, 2014-06-26 at 12:33 +1000, David Holmes wrote: > >>> > >>> Hi, > >>> > >>> The ptrace issue has been fixed: > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8046408 > >>> > >>> but it is in the hs-gc forest and not yet propagated up to jdk9/dev. > >>> > >>> I don't think the format error has been reported yet. > >> > >> > >> David, > >> > >> thanks for the pointer on the ptrace fix. I'm sorry that I didn't check > >> JBS beforehand. > >> > >> I don't have an account in JBS, thus I'm unable to create a bug report > >> for the format error. What would be the right approach here? > > > > > > I have created: > > > > https://bugs.openjdk.java.net/browse/JDK-8048169 > > > > "Incorrect format specifier used in > > src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp:95" > > > > David > > ----- > > > > > >> Regards, > >> Tiago > >> > >>> > >>> David > >>> > >>> On 26/06/2014 4:18 AM, Tiago St?rmer Daitx wrote: > >>>> > >>>> Adding hotspot-dev to the thread. > >>>> > >>>> On Wed, 2014-06-18 at 11:52 -0300, Tiago Sturmer Daitx wrote: > >>>> > >>>> tl;dr I have had problems building JDK9 due to -Werror=format flag on > >>>> gcc/g++ 4.8.2 > >>>> and also due to hotspot/agent/src/os/linux/libproc.h including > >>>> linux/ptrace.h instead of sys/ptrace.h > >>>> > >>>> > >>>> I have been trying to build JDK9 from > >>>> http://hg.openjdk.java.net/jdk9/dev (or /hs-comp or /jdk9) and JDK8u > >>>> from http://hg.openjdk.java.net/jdk8u/jdk8u/ > >>>> > >>>> First, I'm seeing the following on JDK9 only: > >>>> > >>>> > >>>> /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. > >>>> -I/home/tdaitx/jdk9-dev/hotspot/src/share/vm/prims > >>>> -I/home/tdaitx/jdk9-dev/hotspot/sr > >>>> c/share/vm -I/home/tdaitx/jdk9-dev/hotspot/src/share/vm/precompiled > >>>> -I/home/tdaitx/jdk9-dev/hotspot/src/cpu/ppc/vm > >>>> -I/home/tdaitx/jdk9-dev/hot > >>>> spot/src/os_cpu/linux_ppc/vm > >>>> -I/home/tdaitx/jdk9-dev/hotspot/src/os/linux/vm > >>>> -I/home/tdaitx/jdk9-dev/hotspot/src/os/posix/vm -I../generated -D > >>>> HOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"tdaitx\"" > >>>> -DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" > >>>> -DTARGET_ > >>>> OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 > >>>> -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 > >>>> -DTARGET_COMPILER_ > >>>> gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new > >>>> -fvisibility=hidden -m64 -DCC_INTERP -pipe -fno-strict-aliasing -fno > >>>> -omit-frame-pointer -O3 -g -D_LP64=1 -mminimal-toc -mcpu=powerpc64 > >>>> -mtune=power5 -minsert-sched-nops=regroup_exact -mno-multiple > >>>> -mno-string > >>>> -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function > >>>> -Wunused-value -Wformat=2 -Wno-strict-aliasing -Werror > >>>> -DDTRACE_ENABLED -c > >>>> -MMD -MP -MF ../generated/dependencies/bytecodes.o.d -fpch-deps -o > >>>> bytecodes.o > >>>> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecod > >>>> es.cpp > >>>> Compiling /home/tdaitx/jdk9-dev/hotspot/src/cpu/ppc/vm/bytecodes_ppc.cpp > >>>> rm -f bytecodes_ppc.o > >>>> In file included > >>>> from > >>>> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:31:0: > >>>> > >>>> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp: > >>>> In static member function ?static void > >>>> BytecodeInterpreter::run(interpreterState)?: > >>>> > >>>> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp:95:17: > >>>> error: format ?%lx? expects argument of type ?long unsigned int?, but > >>>> argument 5 has type ?DataLayout*? [-Werror=format=] > >>>> ); > >>>> > >>>> Pasted at http://fpaste.org/110642/30430021/ (and there are many many > >>>> lines with > >>>> similar errors until the build is aborted). > >>>> > >>>> After ignoring the error ('CFLAGS="-Wno-error=format" make' or editing > >>>> make/linux/makefiles/gcc.make to remove "-Werror=format"), I get the > >>>> following on JDK9: > >>>> > >>>> > >>>> Making SA debugger back-end... > >>>> /usr/bin/gcc -Dppc64 -D_GNU_SOURCE \ > >>>> -D_FILE_OFFSET_BITS=64 \ > >>>> -g -m64 -shared -fPIC \ > >>>> -I/home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux > >>>> \ > >>>> -I../generated \ > >>>> > >>>> -I/home/tdaitx/build/jdk8-at60-power5/images/j2sdk-image/include > >>>> \ > >>>> > >>>> > >>>> -I/home/tdaitx/build/jdk8-at60-power5/images/j2sdk-image/include/linux > >>>> \ > >>>> > >>>> \ > >>>> > >>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/salibelf.c > >>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/symtab.c > >>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.c > >>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c > >>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_core.c > >>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/LinuxDebuggerLocal.c > >>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/share/native/sadis.c > >>>> \ > >>>> -Xlinker > >>>> > >>>> --version-script=/home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/mapfile > >>>> -Wl,--hash-style=both \ > >>>> \ > >>>> -Wno-strict-aliasing -Werror > >>>> \ > >>>> -o libsaproc.so > >>>> \ > >>>> -lthread_db > >>>> In file included > >>>> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc.h:37:0, > >>>> > >>>> from > >>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.h:30, > >>>> > >>>> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:33: > >>>> /usr/include/linux/ptrace.h:58:8: error: redefinition of ?struct > >>>> ptrace_peeksiginfo_args? > >>>> struct ptrace_peeksiginfo_args { > >>>> ^ > >>>> In file included > >>>> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:32:0: > >>>> /usr/include/sys/ptrace.h:161:8: note: originally defined here > >>>> struct ptrace_peeksiginfo_args > >>>> > >>>> > >>>> Pasted at http://fpaste.org/110640/42657140/ > >>>> > >>>> For JDK8 see: http://fpaste.org/110638/40304229/ > >>>> > >>>> I see that both sys/ptrace.h and linux/ptrace.h have been included: > >>>> > >>>> $ grep -r ptrace.h hotspot/ > >>>> hotspot/agent/src/os/linux/ps_proc.c:#include > >>>> hotspot/agent/src/os/linux/libproc.h:#include > >>>> > >>>> Usually linux/ptrace.h is used by glibc to do syscall, wile sys/ptrace.h > >>>> is used by app code to do library calls (thanks Maynard for the info). > >>>> > >>>> After editing hotspot/agent/src/os/linux/libproc.h to use sys/ptrace.h > >>>> I'm able to build both JDK8 & JDK9. > >>>> > >>>> Some settings: > >>>> > >>>> JDK8 configure: > >>>> $ ./configure \ > >>>> --with-boot-jdk=/home/tdaitx/icedtea7/openjdk.build/j2sdk-image/ \ > >>>> --with-jvm-variants=server --with-jvm-interpreter=cpp \ > >>>> --with-extra-cflags=-Wno-strict-aliasing > >>>> > >>>> JDK9 configure is similar but I point it to a JDK8 build. > >>>> > >>>> Make for JDK8 and JDK9: > >>>> $ make JOBS=8 LOG=debug > >>>> > >>>> > >>>> > >>>> $ /usr/bin/gcc -v # g++ is the same, except for COLLECT_GCC > >>>> Using built-in specs. > >>>> COLLECT_GCC=/usr/bin/gcc > >>>> > >>>> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.8.2/lto-wrapper > >>>> Target: ppc64-redhat-linux > >>>> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > >>>> --infodir=/usr/share/info > >>>> --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap > >>>> --enable-shared --enable-threads=posix --enable-checking=release > >>>> --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions > >>>> --enable-gnu-unique-object --enable-linker-build-id > >>>> --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c > >>>> ++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array > >>>> --enable-java-awt=gtk --disable-dssi > >>>> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre > >>>> --enable-libgcj-multifile --enable-java-maintainer-mode > >>>> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar > >>>> --disable-libjava-multilib > >>>> > >>>> --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-ppc64-redhat-linux/isl-install > >>>> --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-ppc64-redhat-linux/cloog-install > >>>> --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux > >>>> Thread model: posix > >>>> gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) > >>>> > >>>> $ cat /etc/redhat-release > >>>> Fedora release 20 (Heisenbug) > >>>> > >>>> $ rpm -qf /usr/include/linux/ptrace.h > >>>> kernel-headers-3.14.5-200.fc20.ppc64p7 > >>>> > >>>> $ rpm -qf /usr/include/sys/ptrace.h > >>>> glibc-headers-2.18-12.fc20.ppc64p7 > >>>> > >>>> Let me know if you need any additional info. > >>>> > >>>> Regards, > >>>> Tiago > >>>> > >>> > >> > >> > > > -- Tiago St?rmer Daitx Linux Technology Center [LTC|IBM] tdaitx at br.ibm.com From dalibor.topic at oracle.com Thu Sep 4 04:54:31 2014 From: dalibor.topic at oracle.com (dalibor.topic at oracle.com) Date: Thu, 4 Sep 2014 06:54:31 +0200 Subject: JDK8u20 build failure [Was: OpenJDK9 build failure] In-Reply-To: <1409778021.3937.20.camel@ocdc.br.ibm.com> References: <1403103138.3862.274.camel@ocdc.br.ibm.com> <1403720281.3862.336.camel@ocdc.br.ibm.com> <53AB8661.3080606@oracle.com> <1403757793.3862.344.camel@ocdc.br.ibm.com> <53ABC114.4080400@oracle.com> <1409778021.3937.20.camel@ocdc.br.ibm.com> Message-ID: <2BE36C1C-B7CC-44C4-AF2E-2E4B5A8C6461@oracle.com> 8u20 is done, so it's unfortunately too late to get any changes into that release at this point in time. Cheers, Dalibor Topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile:+491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment > On 03.09.2014, at 23:00, Tiago St?rmer Daitx wrote: > >> On Thu, 2014-06-26 at 09:30 +0200, Volker Simonis wrote: >> Hi David, Tiago, >> >> sorry for the daly, but I was on leave during the last two weeks. >> >> I already have a patch for the 'format specifier issue' and will post >> a webrev later today. > > I hit the same issue Today on jdk8u20 from > http://hg.openjdk.java.net/jdk8u/jdk8u20-dev/ > > By looking at bug I see it reports as affecting 8u40 and 9 (I failed to > notice this before), is any fix expected for 8u20 or is it too late for > that? > > Regards, > Tiago > > >> >> @David: thanks for creating the bug! >> >> Regards, >> Volker >> >> >>> On Thu, Jun 26, 2014 at 8:43 AM, David Holmes wrote: >>>> On 26/06/2014 2:43 PM, Tiago St?rmer Daitx wrote: >>>> >>>>> On Thu, 2014-06-26 at 12:33 +1000, David Holmes wrote: >>>>> >>>>> Hi, >>>>> >>>>> The ptrace issue has been fixed: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8046408 >>>>> >>>>> but it is in the hs-gc forest and not yet propagated up to jdk9/dev. >>>>> >>>>> I don't think the format error has been reported yet. >>>> >>>> >>>> David, >>>> >>>> thanks for the pointer on the ptrace fix. I'm sorry that I didn't check >>>> JBS beforehand. >>>> >>>> I don't have an account in JBS, thus I'm unable to create a bug report >>>> for the format error. What would be the right approach here? >>> >>> >>> I have created: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8048169 >>> >>> "Incorrect format specifier used in >>> src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp:95" >>> >>> David >>> ----- >>> >>> >>>> Regards, >>>> Tiago >>>> >>>>> >>>>> David >>>>> >>>>>> On 26/06/2014 4:18 AM, Tiago St?rmer Daitx wrote: >>>>>> >>>>>> Adding hotspot-dev to the thread. >>>>>> >>>>>> On Wed, 2014-06-18 at 11:52 -0300, Tiago Sturmer Daitx wrote: >>>>>> >>>>>> tl;dr I have had problems building JDK9 due to -Werror=format flag on >>>>>> gcc/g++ 4.8.2 >>>>>> and also due to hotspot/agent/src/os/linux/libproc.h including >>>>>> linux/ptrace.h instead of sys/ptrace.h >>>>>> >>>>>> >>>>>> I have been trying to build JDK9 from >>>>>> http://hg.openjdk.java.net/jdk9/dev (or /hs-comp or /jdk9) and JDK8u >>>>>> from http://hg.openjdk.java.net/jdk8u/jdk8u/ >>>>>> >>>>>> First, I'm seeing the following on JDK9 only: >>>>>> >>>>>> >>>>>> /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. >>>>>> -I/home/tdaitx/jdk9-dev/hotspot/src/share/vm/prims >>>>>> -I/home/tdaitx/jdk9-dev/hotspot/sr >>>>>> c/share/vm -I/home/tdaitx/jdk9-dev/hotspot/src/share/vm/precompiled >>>>>> -I/home/tdaitx/jdk9-dev/hotspot/src/cpu/ppc/vm >>>>>> -I/home/tdaitx/jdk9-dev/hot >>>>>> spot/src/os_cpu/linux_ppc/vm >>>>>> -I/home/tdaitx/jdk9-dev/hotspot/src/os/linux/vm >>>>>> -I/home/tdaitx/jdk9-dev/hotspot/src/os/posix/vm -I../generated -D >>>>>> HOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"tdaitx\"" >>>>>> -DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" >>>>>> -DTARGET_ >>>>>> OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 >>>>>> -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 >>>>>> -DTARGET_COMPILER_ >>>>>> gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new >>>>>> -fvisibility=hidden -m64 -DCC_INTERP -pipe -fno-strict-aliasing -fno >>>>>> -omit-frame-pointer -O3 -g -D_LP64=1 -mminimal-toc -mcpu=powerpc64 >>>>>> -mtune=power5 -minsert-sched-nops=regroup_exact -mno-multiple >>>>>> -mno-string >>>>>> -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function >>>>>> -Wunused-value -Wformat=2 -Wno-strict-aliasing -Werror >>>>>> -DDTRACE_ENABLED -c >>>>>> -MMD -MP -MF ../generated/dependencies/bytecodes.o.d -fpch-deps -o >>>>>> bytecodes.o >>>>>> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecod >>>>>> es.cpp >>>>>> Compiling /home/tdaitx/jdk9-dev/hotspot/src/cpu/ppc/vm/bytecodes_ppc.cpp >>>>>> rm -f bytecodes_ppc.o >>>>>> In file included >>>>>> from >>>>>> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:31:0: >>>>>> >>>>>> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp: >>>>>> In static member function ?static void >>>>>> BytecodeInterpreter::run(interpreterState)?: >>>>>> >>>>>> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp:95:17: >>>>>> error: format ?%lx? expects argument of type ?long unsigned int?, but >>>>>> argument 5 has type ?DataLayout*? [-Werror=format=] >>>>>> ); >>>>>> >>>>>> Pasted at http://fpaste.org/110642/30430021/ (and there are many many >>>>>> lines with >>>>>> similar errors until the build is aborted). >>>>>> >>>>>> After ignoring the error ('CFLAGS="-Wno-error=format" make' or editing >>>>>> make/linux/makefiles/gcc.make to remove "-Werror=format"), I get the >>>>>> following on JDK9: >>>>>> >>>>>> >>>>>> Making SA debugger back-end... >>>>>> /usr/bin/gcc -Dppc64 -D_GNU_SOURCE \ >>>>>> -D_FILE_OFFSET_BITS=64 \ >>>>>> -g -m64 -shared -fPIC \ >>>>>> -I/home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux >>>>>> \ >>>>>> -I../generated \ >>>>>> >>>>>> -I/home/tdaitx/build/jdk8-at60-power5/images/j2sdk-image/include >>>>>> \ >>>>>> >>>>>> >>>>>> -I/home/tdaitx/build/jdk8-at60-power5/images/j2sdk-image/include/linux >>>>>> \ >>>>>> >>>>>> \ >>>>>> >>>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/salibelf.c >>>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/symtab.c >>>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.c >>>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c >>>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_core.c >>>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/LinuxDebuggerLocal.c >>>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/share/native/sadis.c >>>>>> \ >>>>>> -Xlinker >>>>>> >>>>>> --version-script=/home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/mapfile >>>>>> -Wl,--hash-style=both \ >>>>>> \ >>>>>> -Wno-strict-aliasing -Werror >>>>>> \ >>>>>> -o libsaproc.so >>>>>> \ >>>>>> -lthread_db >>>>>> In file included >>>>>> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc.h:37:0, >>>>>> >>>>>> from >>>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.h:30, >>>>>> >>>>>> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:33: >>>>>> /usr/include/linux/ptrace.h:58:8: error: redefinition of ?struct >>>>>> ptrace_peeksiginfo_args? >>>>>> struct ptrace_peeksiginfo_args { >>>>>> ^ >>>>>> In file included >>>>>> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:32:0: >>>>>> /usr/include/sys/ptrace.h:161:8: note: originally defined here >>>>>> struct ptrace_peeksiginfo_args >>>>>> >>>>>> >>>>>> Pasted at http://fpaste.org/110640/42657140/ >>>>>> >>>>>> For JDK8 see: http://fpaste.org/110638/40304229/ >>>>>> >>>>>> I see that both sys/ptrace.h and linux/ptrace.h have been included: >>>>>> >>>>>> $ grep -r ptrace.h hotspot/ >>>>>> hotspot/agent/src/os/linux/ps_proc.c:#include >>>>>> hotspot/agent/src/os/linux/libproc.h:#include >>>>>> >>>>>> Usually linux/ptrace.h is used by glibc to do syscall, wile sys/ptrace.h >>>>>> is used by app code to do library calls (thanks Maynard for the info). >>>>>> >>>>>> After editing hotspot/agent/src/os/linux/libproc.h to use sys/ptrace.h >>>>>> I'm able to build both JDK8 & JDK9. >>>>>> >>>>>> Some settings: >>>>>> >>>>>> JDK8 configure: >>>>>> $ ./configure \ >>>>>> --with-boot-jdk=/home/tdaitx/icedtea7/openjdk.build/j2sdk-image/ \ >>>>>> --with-jvm-variants=server --with-jvm-interpreter=cpp \ >>>>>> --with-extra-cflags=-Wno-strict-aliasing >>>>>> >>>>>> JDK9 configure is similar but I point it to a JDK8 build. >>>>>> >>>>>> Make for JDK8 and JDK9: >>>>>> $ make JOBS=8 LOG=debug >>>>>> >>>>>> >>>>>> >>>>>> $ /usr/bin/gcc -v # g++ is the same, except for COLLECT_GCC >>>>>> Using built-in specs. >>>>>> COLLECT_GCC=/usr/bin/gcc >>>>>> >>>>>> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.8.2/lto-wrapper >>>>>> Target: ppc64-redhat-linux >>>>>> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man >>>>>> --infodir=/usr/share/info >>>>>> --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap >>>>>> --enable-shared --enable-threads=posix --enable-checking=release >>>>>> --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions >>>>>> --enable-gnu-unique-object --enable-linker-build-id >>>>>> --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c >>>>>> ++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array >>>>>> --enable-java-awt=gtk --disable-dssi >>>>>> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre >>>>>> --enable-libgcj-multifile --enable-java-maintainer-mode >>>>>> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar >>>>>> --disable-libjava-multilib >>>>>> >>>>>> --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-ppc64-redhat-linux/isl-install >>>>>> --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-ppc64-redhat-linux/cloog-install >>>>>> --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux >>>>>> Thread model: posix >>>>>> gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) >>>>>> >>>>>> $ cat /etc/redhat-release >>>>>> Fedora release 20 (Heisenbug) >>>>>> >>>>>> $ rpm -qf /usr/include/linux/ptrace.h >>>>>> kernel-headers-3.14.5-200.fc20.ppc64p7 >>>>>> >>>>>> $ rpm -qf /usr/include/sys/ptrace.h >>>>>> glibc-headers-2.18-12.fc20.ppc64p7 >>>>>> >>>>>> Let me know if you need any additional info. >>>>>> >>>>>> Regards, >>>>>> Tiago > > > -- > Tiago St?rmer Daitx > Linux Technology Center [LTC|IBM] > tdaitx at br.ibm.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdaitx at br.ibm.com Sat Sep 6 05:29:28 2014 From: tdaitx at br.ibm.com (Tiago =?ISO-8859-1?Q?St=FCrmer?= Daitx) Date: Sat, 06 Sep 2014 02:29:28 -0300 Subject: Template interpreter status in JDK7/IcedTea 2.5.2 for PPC64/PPC64LE Message-ID: <1409981368.3930.9.camel@ocdc.br.ibm.com> All- What's the status of the template interpreter for JDK7 in the ppc-aix-port? I can see that JDK 9 does build with the Template Interpreter for both PPC64 and PPC64LE, but JDK7 seems to be still using the C++ Interpreter on both archs - at least when build from IcedTea 2.5.2, which supposedly merged the head from PPC-AIX-Port repo (I haven't build JDK 7 directly from the PPC-AIX-Port repo to compare the results... yet). What am I missing? How should/can I be sure to enable the template interpreter in a JDK7 build? I used $ nm -C libjvm.so | grep TemplateTable::initialize $ nm -C libjvm.so | grep CppInterpreter::initialize to identify which interpreter was build (stolen from [1]), let me know if there an easier way to do that. Regards, Tiago [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-October/011431.html -- Tiago St?rmer Daitx Linux Technology Center [LTC|IBM] tdaitx at br.ibm.com From volker.simonis at gmail.com Mon Sep 8 09:32:37 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Sep 2014 11:32:37 +0200 Subject: Template interpreter status in JDK7/IcedTea 2.5.2 for PPC64/PPC64LE Message-ID: Hi Tiago, we already have the template interpreter in our http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot repository (even for ppc64le :) since quite some time (~March 2014). See: 8050942: PPC64: implement template interpreter for ppc64le http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/1176e8ff9f90 New files for template interpreter Missed from 8036976: PPC64: implement the template interpreter http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/6f0b8f13db4d 8036976: PPC64: implement the template interpreter http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/7b62421e491e Without additional parameters the template interpreter is being build as the default interpreter on ppc64 - at least if you build right from our PPC-AIX-Port repository (see for example http://cr.openjdk.java.net/~simonis/ppc-aix-port/logs/linuxppc64/nightly/output-jdk7u-fastdebug.log.gz for recent build logs). Maybe the IcedTea build still sets "CC_INTERP=true" when building on linux/ppc64? This isn't required any more and should be removed as we don't actively support the cpp interpreter any more. Regarding the question on how to detect the template interpreter - I don't know a perfect answer either. But you could for example use "-XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter". If you're running with the template interpreter, the output will be much longer and print the code templates for each bytecode (if you have the hsdis-ppc64.so library in the library path it will even print the disassembly of each bytecode tempalate). Regards, Volker On Sat, Sep 6, 2014 at 7:29 AM, Tiago St?rmer Daitx wrote: > All- > > What's the status of the template interpreter for JDK7 in the > ppc-aix-port? > > I can see that JDK 9 does build with the Template Interpreter for both > PPC64 and PPC64LE, but JDK7 seems to be still using the C++ Interpreter > on both archs - at least when build from IcedTea 2.5.2, which supposedly > merged the head from PPC-AIX-Port repo (I haven't build JDK 7 directly > from the PPC-AIX-Port repo to compare the results... yet). > > What am I missing? How should/can I be sure to enable the template > interpreter in a JDK7 build? > > I used > > $ nm -C libjvm.so | grep TemplateTable::initialize > $ nm -C libjvm.so | grep CppInterpreter::initialize > > to identify which interpreter was build (stolen from [1]), let me know > if there an easier way to do that. > > Regards, > Tiago > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-October/011431.html > > > -- > Tiago St?rmer Daitx > Linux Technology Center [LTC|IBM] > tdaitx at br.ibm.com > From gnu.andrew at redhat.com Mon Sep 8 16:00:05 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 8 Sep 2014 12:00:05 -0400 (EDT) Subject: Template interpreter status in JDK7/IcedTea 2.5.2 for PPC64/PPC64LE In-Reply-To: References: Message-ID: <867767601.19633722.1410192005519.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Tiago, > > we already have the template interpreter in our > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot repository (even > for ppc64le :) since quite some time (~March 2014). See: > > 8050942: PPC64: implement template interpreter for ppc64le > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/1176e8ff9f90 > > New files for template interpreter Missed from 8036976: PPC64: > implement the template interpreter > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/6f0b8f13db4d > > 8036976: PPC64: implement the template interpreter > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/7b62421e491e > > Without additional parameters the template interpreter is being build > as the default interpreter on ppc64 - at least if you build right from > our PPC-AIX-Port repository (see for example > http://cr.openjdk.java.net/~simonis/ppc-aix-port/logs/linuxppc64/nightly/output-jdk7u-fastdebug.log.gz > for recent build logs). Maybe the IcedTea build still sets > "CC_INTERP=true" when building on linux/ppc64? This isn't required any > more and should be removed as we don't actively support the cpp > interpreter any more. It does. README-ppc.html still says it should. I never understood why it wasn't just set by the makefiles anyway, then you could have taken it out again when it was no longer needed. Instead, we end up with dated build instructions like this :( To be specific, IcedTea has: ifeq ($(ARCH), ppc64) CC_INTERP=true endif and I'll now remove this for 2.5.3. > > Regarding the question on how to detect the template interpreter - I > don't know a perfect answer either. But you could for example use > "-XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter". If you're > running with the template interpreter, the output will be much longer > and print the code templates for each bytecode (if you have the > hsdis-ppc64.so library in the library path it will even print the > disassembly of each bytecode tempalate). > > Regards, > Volker > > On Sat, Sep 6, 2014 at 7:29 AM, Tiago St?rmer Daitx > wrote: > > All- > > > > What's the status of the template interpreter for JDK7 in the > > ppc-aix-port? > > > > I can see that JDK 9 does build with the Template Interpreter for both > > PPC64 and PPC64LE, but JDK7 seems to be still using the C++ Interpreter > > on both archs - at least when build from IcedTea 2.5.2, which supposedly > > merged the head from PPC-AIX-Port repo (I haven't build JDK 7 directly > > from the PPC-AIX-Port repo to compare the results... yet). > > > > What am I missing? How should/can I be sure to enable the template > > interpreter in a JDK7 build? > > > > I used > > > > $ nm -C libjvm.so | grep TemplateTable::initialize > > $ nm -C libjvm.so | grep CppInterpreter::initialize > > > > to identify which interpreter was build (stolen from [1]), let me know > > if there an easier way to do that. > > > > Regards, > > Tiago > > > > [1] > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-October/011431.html > > > > > > -- > > Tiago St?rmer Daitx > > Linux Technology Center [LTC|IBM] > > tdaitx at br.ibm.com > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From maynardj at us.ibm.com Mon Sep 29 22:42:14 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Mon, 29 Sep 2014 17:42:14 -0500 Subject: PowerPC: core file option not available with serviceability tools In-Reply-To: References: <53B5A92A.401@us.ibm.com> <53BD477D.2090107@us.ibm.com> Message-ID: <5429E046.8030003@us.ibm.com> On 07/09/2014 12:38 PM, Volker Simonis wrote: > On Wed, Jul 9, 2014 at 3:45 PM, Maynard Johnson wrote: >> On 07/04/2014 10:59 AM, Volker Simonis wrote: >>> Hi Maynard, >>> >>> we (i.e. SAP) do not currently support the SA agent on Linux/PPC64 and >>> AIX (we have other proprietary servicibility tools). Because of that >>> (and because SA isn't specified by the SE specification) porting the >>> SA agent was no top priority until now. But there are no technical >>> reasons why it should not work (it's just a lack of resources). Of >>> course contributions are always highly welcome:) >>> >>> That said, the SA agent library and jar file actually gets build. If >>> you do a complete build you'll find them under: >>> >>> hotspot/linux_ppc64_compiler2/generated/sa-jdi.jar >>> hotspot/linux_ppc64_compiler2/{product,fastdebug,debug}/libsaproc.so >>> >>> in the build directory. They are just not copied into the jdk >>> workspace and the created images because they don't work out of the >>> box. >>> >>> The following two patches for the jdk9 top-level and hotspot >>> repositories respectively should fix the build such that the agent >>> files will be correctly copied into the images. >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/sa_toplevel >>> http://cr.openjdk.java.net/~simonis/webrevs/sa_hotspot/ >>> >>> They will get you to the point where for example 'jstack' will run up >>> to the following point: >> Ok, great. This should be enough to get me started. I should have time to begin on this later this week or early next week. > > Hi Maynard, > > great to welcome you in the ppc64 porting team:) > >> I may come knocking at your "door" for some occasional help, but I'll try to keep that to a minimum. Hi, Volker. Knock, knock. :-) I was preoccupied for a while this summer rolling out the latest release of oprofile (for which I'm the maintainer), but am now coming back to this task. I've implemented what I believe are all of the necessary ppc64-specific Java files to enable the jstack and jmap tools to work on core files. I've also updated hotspot/agent/src/os/linux/LinuxDebuggerLocal.c to implement the accumulation of register data on ppc64 vi ptrace. But now I've run into a problem I need help with. When I run jstack on my POWER7 system, it gets stuck in a loop in sun.jvm.hotspot.tools.StackTrace::run. There's an inner for-loop there where cur.getLastJavaVFrameDbg() is called ('cur' is a JavaThread). For the first JavaThread, we do return from getLastJavaVFrameDbg(), just as we do when running jstack on my Intel laptop. But for the second JavaThread, we never return from getLastJavaVFrameDbg() on ppc64. I believe the root of the problem is in my new sun.jvm.hotspot.runtime.ppc64.PPC64Frame class. The getLastJavaVFrameDbg method calls getCurrentFrameGuess, which is implemented in the new sun.jvm.hotspot.runtime.linux_ppc64.LinuxPPC64JavaThreadPDAccess class. In both ppc64 and x86, this first level xxxCurrentFrameGuess object is instantiated with a 'pc' value of null, so getCurrentFrameGuess then new's up a xxxFrame object, passing in the SP and FP, but no PC. The implementation of the PPC64Frame(Address,Address) constructor is currently identical to the X86Frame cons! tructor, b ut is almost certainly incorrect. In this constructor, the 'pc' is set as follows: this.pc = raw_sp.getAddressAt(-1 * VM.getVM().getAddressSize()); This works fine on X86, but not on ppc64. But I'm not understanding how this even works on X86. From what I understand, the data below the stack pointer on X86 is the "red zone". How is that being used as a pc? But more importantly, do you know how I can ascertain what the 'pc' value should be for ppc64? Thanks in advance for any assistance you can give. -Maynard > > Please feel free to ask any questions. The OpenJDK project and > especially the HotSpot part are known to take some getting used to. > >> I was wondering if a bug report should be opened in JBS, just to record that the issue is being worked. Thoughts? > > I have opened "8049715: PPC64: First steps to enable SA on > Linux/PPC64" (https://bugs.openjdk.java.net/browse/JDK-8049715) for > the patch which I sent you with the last mail. I've already sent out > webrevs for that change and hopefully it will be fixed within the next > few days. > > For the actual port of the ppc64-specific stuff I opened bug "8049716 > PPC64: Implement SA on Linux/PPC64" > (https://bugs.openjdk.java.net/browse/JDK-8049716). I can also help > with hosting the webrevs, once you have a running version. > > Regards, > Volker > >> >> -Maynard >>> >>>> images/j2sdk-image/bin/jstack ./jdk/bin/java core.13547 >>> Attaching to core core.13547 from executable ./jdk/bin/java, please wait... >>> WARNING: Hotspot VM version >>> 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00 does not match with >>> SA version 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00. You may >>> see unexpected results. >>> Debugger attached successfully. >>> Server compiler detected. >>> JVM version is 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00 >>> Deadlock Detection: >>> >>> Exception in thread "main" java.lang.reflect.InvocationTargetException >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:484) >>> at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) >>> at sun.tools.jstack.JStack.main(JStack.java:106) >>> Caused by: java.lang.ExceptionInInitializerError >>> at sun.jvm.hotspot.runtime.VM.getThreads(VM.java:610) >>> at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:54) >>> at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) >>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:62) >>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) >>> at sun.jvm.hotspot.tools.JStack.run(JStack.java:66) >>> at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >>> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >>> at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >>> at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) >>> ... 6 more >>> Caused by: java.lang.RuntimeException: OS/CPU combination linux/ppc64 >>> not yet supported >>> at sun.jvm.hotspot.runtime.Threads.initialize(Threads.java:97) >>> at sun.jvm.hotspot.runtime.Threads.access$000(Threads.java:42) >>> at sun.jvm.hotspot.runtime.Threads$1.update(Threads.java:52) >>> at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:394) >>> at sun.jvm.hotspot.runtime.Threads.(Threads.java:50) >>> ... 16 more >>> >>> And that's the point where I was saying that "contributions are always >>> highly welcome:)" >>> >>> Now all the Linux/PPC64 specific class under >>> hotspot/agent/src/share/classes/ would have to be implemented (e.g. >>> sun/jvm/hotspot/runtime/amd64/AMD64CurrentFrameGuess). Are you >>> interested in contributing to this project? >>> >>> Regards, >>> Volker >>> >>> PS: I cc-ed serviceability-dev because I remember that they started a >>> poll a while ago about who is using the SA tools. I'm therefore not >>> quite sure what's the current status and what are the future plan for >>> these libraries. >>> >>> >>> On Thu, Jul 3, 2014 at 9:04 PM, Maynard Johnson wrote: >>>> Hi, all, >>>> On my Intel laptop, I note that certain jdk9 serviceability tools -- jstack, jmap, jsadebugd -- have an option to pass a core file instead of a process ID; for example: >>>> >>>> $ jstack -h >>>> Usage: >>>> jstack [-l] >>>> (to connect to running process) >>>> jstack -F [-m] [-l] >>>> (to connect to a hung process) >>>> jstack [-m] [-l] >>>> (to connect to a core file) >>>> jstack [-m] [-l] [server_id@] >>>> (to connect to a remote debug server) >>>> >>>> But on my PowerLinux box, the core file option is missing from the usage output. I see that jdk9-dev/jdk/src/share/classes/sun/tools/jstack/JStack.java requires the existence of sun.jvm.hotspot.tools.JStack for the core file option to be made available. On my Intel system, the sun.jvm.hotspot.tools.JStack class is packaged in sa-jdi.jar in /jvm/openjdk-1.9.0-internal/lib/. But the sa-jdi.jar is missing on PowerPC. Is there a technical reason for this or is it an oversight? >>>> >>>> The jsadebugd tool does not run at all on PowerLinux; it gets the following error: >>>> >>>> Error: Could not find or load main class sun.jvm.hotspot.jdi.SADebugServer >>>> >>>> On my Intel system, the SADebugServer class is packaged in the sa-jdi.jar mentioned above. >>>> >>>> I've spent the past day or so looking at makefiles until I'm cross-eyed, but haven't yet found where the issue might be. Any tips would be appreciated. >>>> >>>> Thanks. >>>> -Maynard >>>> >>> >> >