FreeBSD -CURRENT plans to update base Clang to 6.0.0 soon. While testing this port failed to build. In file included from hotspot/src/share/vm/utilities/accessFlags.cpp:26: In file included from hotspot/src/share/vm/oops/oop.inline.hpp:28: In file included from hotspot/src/share/vm/gc_implementation/shared/ageTable.hpp:30: In file included from hotspot/src/share/vm/runtime/perfData.hpp:28: In file included from hotspot/src/share/vm/memory/allocation.inline.hpp:28: In file included from hotspot/src/share/vm/runtime/atomic.inline.hpp:70: hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:95:21: error: unknown token in expression __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)" ^ hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:48:24: note: expanded from macro 'LOCK_IF_MP' #define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: " ^ <inline asm>:1:30: note: instantiated into assembly here cmp $0, %esi; je 1f; lock; 1: cmpxchgl %ecx,(%edi) ^ To reproduce: $ poudriere jail -cj clang6-amd64 -a amd64 -v projects/clang600-import -m svn+https $ poudriere bulk -Ctj clang6-amd64 java/openjdk6 java/openjdk7 java/openjdk8 http://package18.nyi.freebsd.org/data/headamd64PR224669-default/2018-01-10_07h00m34s/logs/errors/openjdk6-b44,1.log http://package18.nyi.freebsd.org/data/headamd64PR224669-default/2018-01-10_07h00m34s/logs/errors/openjdk8-8.152.16_2.log http://package18.nyi.freebsd.org/data/headi386PR224669-default/2018-01-09_21h45m33s/logs/errors/openjdk6-b44,1.log http://package18.nyi.freebsd.org/data/headi386PR224669-default/2018-01-09_21h45m33s/logs/errors/openjdk8-8.152.16_2.log
Created attachment 189594 [details] blind fix: use "lock" as prefix My guess, Clang integrated assembler no longer accepts "lock" as standalone instruction.
This patch does not look good. The previous inline assembly should generate something like this: je .Ltmp0 lock .Ltmp0: cmpxchgl %ecx, (%edi) Assembled: 4: 0f 84 01 00 00 00 je b <test+0xb> a: f0 67 0f b1 0f lock addr32 cmpxchg %ecx,(%edi) Your patch will generate something like this: je .Ltmp0 .Ltmp0: lock cmpxchgl %ecx, (%edi) Assembled: 4: 0f 84 00 00 00 00 je a <test+0xa> a: f0 67 0f b1 0f lock addr32 cmpxchg %ecx,(%edi) As you can see, this patch *always* adds the prefix for cmpxchg.
Can you please try something like this? +-#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: " ++#define LOCK_IF_MP(mp) "cmp $0, " #mp "\nje 1f\nlock\n1: "
No joy with \n In file included from hotspot/src/share/vm/runtime/atomic.inline.hpp:70: hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:95:21: error: unknown token in expression __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)" ^ hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:48:55: note: expanded from macro 'LOCK_IF_MP' #define LOCK_IF_MP(mp) "cmp $0, " #mp "\nje 1f\nlock\n1: " ^ <inline asm>:4:2: note: instantiated into assembly here 1: cmpxchgl %ecx,(%rdi) ^ openjdk6 - https://ptpb.pw/6chE openjdk8 - https://ptpb.pw/CXbx openjdk7 is also affected by In file included from hotspot/src/share/vm/precompiled/precompiled.hpp:259: In file included from hotspot/src/share/vm/opto/addnode.hpp:28: In file included from hotspot/src/share/vm/opto/node.hpp:30: In file included from hotspot/src/share/vm/opto/compile.hpp:44: In file included from hotspot/src/share/vm/trace/tracing.hpp:28: In file included from ../generated/tracefiles/traceEventClasses.hpp:18: hotspot/src/share/vm/trace/traceStream.hpp:44:22: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal] _st.print("%s = "UINT32_FORMAT, label, val); ^ hotspot/src/share/vm/trace/traceStream.hpp:48:22: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal] _st.print("%s = "UINT32_FORMAT, label, val); ^ hotspot/src/share/vm/trace/traceStream.hpp:52:22: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal] _st.print("%s = "INT32_FORMAT, label, val); ^ hotspot/src/share/vm/trace/traceStream.hpp:56:22: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal] _st.print("%s = "UINT32_FORMAT, label, val); ^ http://package18.nyi.freebsd.org/data/headi386PR224669-default/2018-01-07_22h53m03s/logs/errors/openjdk-7.151.01,1.log
Dimitry, can you find Clang commit that changed integrated assembler in order for us to better understand the rationale?
(In reply to Jan Beich from comment #4) That's bad. :-( Then, I guess we have no choice but to do something like this: +-#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: " ++#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; .byte 0xf0; 1: "
(In reply to Jan Beich from comment #5) > Dimitry, can you find Clang commit that changed integrated assembler in > order for us to better understand the rationale? Yes, this was caused by https://reviews.llvm.org/rL315899; the changes were for "better" rep/lock prefix support, but I filed several severe regression bugs, after noticing these during world and ports builds, see: * https://bugs.llvm.org/show_bug.cgi?id=35741 (comments after x86 prefixes cause errors ) * https://bugs.llvm.org/show_bug.cgi?id=35749 (.byte directives after x86 prefixes cause errors) * https://bugs.llvm.org/show_bug.cgi?id=35831 (labels after x86 prefixes cause errors) The first bug was fixed fairly quickly, but there has been no movement on the other two, and I think it is likely that more edge cases exist. I asked in PR35749 whether the release manager will consider reverting the upstream change in the 6.0.0 branch, since this regressed so much. I will ask again. > (In reply to Jung-uk Kim from comment #6) > (In reply to Jan Beich from comment #4) > > That's bad. :-( > > Then, I guess we have no choice but to do something like this: > > +-#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: " > ++#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; .byte 0xf0; 1: " Yes, that is the workaround I put in my local ports tree too. But I hate it :(
Dimitry, does openjdk8 actually work for you? Clang 6 probably misoptimizes it. $ gdb -q /usr/local/openjdk8/bin/java Reading symbols from /usr/local/openjdk8/bin/java...(no debugging symbols found)...done. (gdb) r Starting program: /usr/local/openjdk8/bin/java Program received signal SIGSEGV, Segmentation fault. 0x00000008023c7896 in NativeCallStack::NativeCallStack(int, bool) () from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so (gdb) bt #0 0x00000008023c7896 in NativeCallStack::NativeCallStack(int, bool) () from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so #1 0x0000000802382f4e in MemTracker::init_tracking_level() () from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so #2 0x0000000801ebccb2 in ResourceObj::operator new(unsigned long, ResourceObj::allocation_type, MemoryType) () from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so #3 0x000000080245bb2a in _GLOBAL__sub_I_reflectionUtils.cpp () from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so #4 0x0000000802588ff2 in __do_global_ctors_aux () from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so #5 0x0000000801df331e in _init () from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so #6 0x00007fffffffd110 in ?? () #7 0x00000008006056ba in objlist_call_init (list=<optimized out>, lockstate=<optimized out>) at /usr/src/libexec/rtld-elf/rtld.c:2672 #8 0x0000000800609e39 in dlopen_object (name=0x800629400 "z\270P\325", fd=<optimized out>, refobj=<optimized out>, lo_flags=2, mode=258, lockstate=0x2) at /usr/src/libexec/rtld-elf/rtld.c:3391 #9 0x0000000800606836 in rtld_dlopen ( name=0x7fffffffe6d0 "/usr/local/openjdk8/jre/lib/amd64/server/libjvm.so", fd=-1, mode=<optimized out>) at /usr/src/libexec/rtld-elf/rtld.c:3266 #10 0x00000008008293fe in LoadJavaVM () from /usr/local/openjdk8/bin/../lib/amd64/jli/libjli.so #11 0x0000000800824d88 in JLI_Launch () from /usr/local/openjdk8/bin/../lib/amd64/jli/libjli.so #12 0x00000000004008ab in main ()
(In reply to Jan Beich from comment #8) > Dimitry, does openjdk8 actually work for you? Clang 6 probably misoptimizes > it. Not sure about misoptimizing, but it does indeed crash: Program received signal SIGSEGV, Segmentation fault. NativeCallStack::NativeCallStack (this=0x800e6a7a0 <NativeCallStack::EMPTY_STACK>, toSkip=0, fillStack=false) at /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/utilities/nativeCallStack.cpp:33 33 _hash_value(0) { (gdb) bt #0 NativeCallStack::NativeCallStack (this=0x800e6a7a0 <NativeCallStack::EMPTY_STACK>, toSkip=0, fillStack=false) at /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/utilities/nativeCallStack.cpp:33 #1 0x0000000801732d7e in MemTracker::init_tracking_level () at /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/services/memTracker.cpp:72 #2 0x000000080126cb62 in MemTracker::tracking_level () at /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/services/memTracker.hpp:118 #3 ResourceObj::operator new (size=32, type=ResourceObj::STACK_OR_EMBEDDED, flags=mtInternal) at /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/memory/allocation.cpp:89 #4 0x000000080180b93a in _GLOBAL__sub_I_reflectionUtils.cpp () at /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/runtime/reflectionUtils.cpp:72 #5 0x0000000801939182 in __do_global_ctors_aux () from /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so #6 0x00000008019391a6 in _init () from /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so #7 0x00007fffffffc8f0 in ?? () #8 0x000000080020d06a in objlist_call_init (list=<optimized out>, lockstate=<optimized out>) at /usr/src/libexec/rtld-elf/rtld.c:2672 #9 0x00000008002117e9 in dlopen_object (name=0x80022f800 "z\270P\325", fd=<optimized out>, refobj=<optimized out>, lo_flags=2, mode=258, lockstate=0x772f386b00000002) at /usr/src/libexec/rtld-elf/rtld.c:3391 #10 0x000000080020e1e6 in rtld_dlopen (name=0x7fffffffdeb0 "/wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so", fd=-1, mode=<optimized out>) at /usr/src/libexec/rtld-elf/rtld.c:3266 #11 0x000000080025136e in LoadJavaVM () from /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-server-release/jdk/bin/../lib/amd64/jli/libjli.so #12 0x000000080024ccf8 in JLI_Launch () from /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-server-release/jdk/bin/../lib/amd64/jli/libjli.so #13 0x000000000020130b in main () (gdb) print *this $2 = {<StackObj> = {<No data fields>}, static EMPTY_STACK = {<StackObj> = {<No data fields>}, static EMPTY_STACK = <same as static member of an already seen type>, _stack = {0x0, 0x0, 0x0, 0x0}, _hash_value = 0}, _stack = {0x0, 0x0, 0x0, 0x0}, _hash_value = 0} (gdb) disassemble Dump of assembler code for function NativeCallStack::NativeCallStack(int, bool): 0x00000008017776c0 <+0>: push %rbp 0x00000008017776c1 <+1>: mov %rsp,%rbp 0x00000008017776c4 <+4>: mov %esi,%eax => 0x00000008017776c6 <+6>: movl $0x0,0x20(%rdi) 0x00000008017776cd <+13>: test %edx,%edx 0x00000008017776cf <+15>: je 0x8017776de <NativeCallStack::NativeCallStack(int, bool)+30> 0x00000008017776d1 <+17>: mov $0x4,%esi 0x00000008017776d6 <+22>: mov %eax,%edx 0x00000008017776d8 <+24>: pop %rbp 0x00000008017776d9 <+25>: jmpq 0x8017aa290 <os::get_native_stack(unsigned char**, int, int)> 0x00000008017776de <+30>: xorps %xmm0,%xmm0 0x00000008017776e1 <+33>: movups %xmm0,0x10(%rdi) 0x00000008017776e5 <+37>: movups %xmm0,(%rdi) 0x00000008017776e8 <+40>: pop %rbp 0x00000008017776e9 <+41>: retq End of assembler dump. (gdb) print &this->_hash_value $4 = (int *) 0x800e6a7c0 <NativeCallStack::EMPTY_STACK+32> (gdb) info registers rax 0x0 0 rbx 0x0 0 rcx 0x0 0 rdx 0x0 0 rsi 0x0 0 rdi 0x800e6a7a0 34374854560 rbp 0x7fffffffc320 0x7fffffffc320 rsp 0x7fffffffc320 0x7fffffffc320 r8 0xfffffff5 4294967285 r9 0xffffffff81c1b688 -2118011256 r10 0x800e72e5c 34374889052 r11 0x7fffffffc0c8 140737488339144 r12 0x80022f9f0 34362030576 r13 0x2 2 r14 0x7fffffffc370 140737488339824 r15 0x8006a8a40 34366720576 rip 0x8017776c6 0x8017776c6 <NativeCallStack::NativeCallStack(int, bool)+6> eflags 0x10246 [ PF ZF IF RF ] cs 0x43 67 ss 0x3b 59 ds <unavailable> es <unavailable> fs <unavailable> gs <unavailable> fs_base 0x8002318b0 34362038448 gs_base 0x0 0 So the address of the _hash_value field is OK, apparently. As to why this gives a segfault, no idea yet.
(In reply to Dimitry Andric from comment #9) > So the address of the _hash_value field is OK, apparently. As to why this > gives a segfault, no idea yet. Actually, it is quite clear: the memory is read-only. openjdk/hotspot/src/share/vm/utilities/nativeCallStack.cpp has: 28 #include "utilities/nativeCallStack.hpp" 29 30 const NativeCallStack NativeCallStack::EMPTY_STACK(0, false); 31 32 NativeCallStack::NativeCallStack(int toSkip, bool fillStack) : 33 _hash_value(0) { 34 I.e. NativeCallStack::EMPTY_STACK is const, and placed into .rodata. Then openjdk/hotspot/src/share/vm/services/memTracker.cpp has: 70 // Construct NativeCallStack::EMPTY_STACK. It may get constructed twice, 71 // but it is benign, the results are the same. 72 ::new ((void*)&NativeCallStack::EMPTY_STACK) NativeCallStack(0, false); This new invocation cannot work, because it tries to re-initialize a const object. Why this worked in previous clang, or in any other compiler, I don't know. :)
The upstream commit that causes this problem is here: http://hg.openjdk.java.net/jdk/hs/rev/35e11b657728 They apparently used to have a r/w emptyStack variable in their memTracker.cpp, but due to some issue with a "minimal build" (whatever that is), they started explicitly initializing it using placement new. However, they also moved the variable into the NativeCallStack class, but as a static const member! That simply cannot be right in any way.
Created attachment 189672 [details] clang 6 fixes for openjdk8 With the attached patch, I can build and run openjdk8. I have built a few openjdk8-dependent ports, and ran them with light testing, all seems to work fine. 1) patch-hotspot_src_os__cpu_bsd__x86_vm_atomic__bsd__x86.inline.hpp: replaces a lock prefix before a label with a .byte directive 2) patch-hotspot_src_os__cpu_bsd__x86_vm_bsd__x86__32.s: idem 3) patch-hotspot_src_share_vm_services_memTracker.cpp: removes the placement new that tries to reinitialize a static const object
base r328090 should fix the issues with the LOCK_IF_MP macro. For some reason, bugzilla hasn't picked up the PR: line, though.
A commit references this bug: Author: jkim Date: Thu Jan 18 01:58:20 UTC 2018 New revision: 459311 URL: https://svnweb.freebsd.org/changeset/ports/459311 Log: Fix build with Clang 6.0. Note it is partially merged from the upstream patches for Linux and GCC 6. https://bugs.openjdk.java.net/browse/JDK-8163032 http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/e34324d73cd5 http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/9e1264f51bae PR: 225054 Changes: head/java/openjdk7/files/patch-hotspot_make_bsd_makefiles_gcc.make head/java/openjdk7/files/patch-jdk_make_common_Defs-bsd.gmk
(In reply to Dimitry Andric from comment #13) Yes, base r328090 fixed the problem. Thanks!
Do you mean comment 9 disappeared on its own?
(In reply to Jan Beich from comment #16) > Do you mean comment 9 disappeared on its own? No, only the "unknown token in expression" asm compile error has been fixed by that. The segfault must still be fixed, I guess?
Re-open, the segfault wasn't fixed.
Created attachment 189881 [details] Fix attempt to reinitialize read-only memory (In reply to Antoine Brodin from comment #18) > Re-open, the segfault wasn't fixed. Indeed, please also apply the patch for hotspot/src/share/vm/services/memTracker.cpp, otherwise it will still attempt to reinitialize read-only memory.
*** Bug 225249 has been marked as a duplicate of this bug. ***
(In reply to Dimitry Andric from comment #19) Okay, I'll take care of this.
A commit references this bug: Author: jkim Date: Thu Jan 18 19:26:27 UTC 2018 New revision: 459368 URL: https://svnweb.freebsd.org/changeset/ports/459368 Log: Fix a run-time crash with Clang 6.0. Note this problem was introduced with fixes for JDK-8055007. https://bugs.java.com/view_bug.do?bug_id=8055007 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/changeset/c6211b707068 PR: 225054 Changes: head/java/openjdk8/Makefile head/java/openjdk8/files/patch-hotspot_src_share_vm_services_memTracker.cpp
Committed, thanks!
A commit references this bug: Author: swills Date: Fri Feb 23 18:15:00 UTC 2018 New revision: 462712 URL: https://svnweb.freebsd.org/changeset/ports/462712 Log: MFH: r459311 Fix build with Clang 6.0. Note it is partially merged from the upstream patches for Linux and GCC 6. https://bugs.openjdk.java.net/browse/JDK-8163032 http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/e34324d73cd5 http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/9e1264f51bae PR: 225054 Approved by: ports-secteam (implicit) Changes: _U branches/2018Q1/ branches/2018Q1/java/openjdk7/files/patch-hotspot_make_bsd_makefiles_gcc.make branches/2018Q1/java/openjdk7/files/patch-jdk_make_common_Defs-bsd.gmk
A commit references this bug: Author: swills Date: Fri Feb 23 18:15:54 UTC 2018 New revision: 462713 URL: https://svnweb.freebsd.org/changeset/ports/462713 Log: MFH: r459368 Fix a run-time crash with Clang 6.0. Note this problem was introduced with fixes for JDK-8055007. https://bugs.java.com/view_bug.do?bug_id=8055007 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/changeset/c6211b707068 PR: 225054 Approved by: ports-secteam (implicit) Changes: _U branches/2018Q1/ branches/2018Q1/java/openjdk8/Makefile branches/2018Q1/java/openjdk8/files/patch-hotspot_src_share_vm_services_memTracker.cpp