Error building hotspot with shark/zero (original) (raw)

Neale Ferguson neale at sinenomine.net
Wed Feb 5 20:30:23 PST 2014

I simply followed the instructions and did a hg clone and then used the get_source script to populate everything.

I did find a patch that removed generate_stubs etc and things ran to completion. There were certain methods that needed adding to sharkMemoryManager such as allocateCodeSection. Other issues included createPHI and CreateCall parameters having changed. Also llvm-config --ldflags doesn't return -lot info so I had to provide a quick and dirty fix to the generic profile script.

-------- Original message -------- From: Christian Thalinger Date:2014/02/05 23:14 (GMT-05:00) To: Neale Ferguson Cc: hotspot-dev at openjdk.java.net Subject: Re: Error building hotspot with shark/zero

This is odd. What version of OpenJDK 7 are you using as this got fixed a long time ago:

https://bugs.openjdk.java.net/browse/JDK-7071823

On Feb 5, 2014, at 7:20 AM, Neale Ferguson <neale at sinenomine.net> wrote:

Getting closer with LLVM 3.4 and openJDK. Everything compiles cleanly now but I now crap out with:

Linking vm... sharedRuntimezero.o: In function SharedRuntime::generatestubs()':_ _sharedRuntimezero.cpp:(.text+0x3bc): multiple definition of SharedRuntime::generatestubs()' sharedRuntime.o:sharedRuntime.cpp:(.text+0x1328): first defined here sharedRuntimezero.o:(.bss+0x18): multiple definition of SharedRuntime::wrongmethodblob'_ _sharedRuntime.o:(.bss+0x0): first defined here_ _sharedRuntimezero.o:(.bss+0x20): multiple definition of SharedRuntime::icmissblob' sharedRuntime.o:(.bss+0x8): first defined here sharedRuntimezero.o:(.bss+0x28): multiple definition of SharedRuntime::resolveoptvirtualcallblob'_ _sharedRuntime.o:(.bss+0x10): first defined here_ _sharedRuntimezero.o:(.bss+0x30): multiple definition of SharedRuntime::resolvevirtualcallblob' sharedRuntime.o:(.bss+0x18): first defined here sharedRuntimezero.o:(.bss+0x38): multiple definition of SharedRuntime::resolvestaticcallblob'_ _sharedRuntime.o:(.bss+0x20): first defined heresharedRuntimezero.o:(.bss+0x8): multiple definition of SharedRuntime::pollingpagesafepointhandlerblob'sharedRuntime.o:(.bss+0x38): first defined heresharedRuntimezero.o:(.bss+0x10): multiple definition of SharedRuntime::pollingpagereturnhandlerblob'sharedRuntime.o:(.bss+0x40): first defined heresharedRuntimezero.o:(.bss+0x0): multiple definition of SharedRuntime::deoptblob'sharedRuntime.o:(.bss+0x28): first defined herecollect2: ld returned 1 exit statusln: accessing libjvm.so.1': Too many levels of symbolic links/usr/bin/chcon: failed to get security context of libjvm.so': Too many levels of symbolic linksERROR: Cannot chcon libjvm.so make[6]: stat: libjvm.so: Too many levels of symbolic links Both sharedRuntime.cpp and sharedRuntimezero.cpp have generatestubs defined and there doesn't appear to be conditional logic that needs to be triggered to stop it, so is it a Makefile thing? As for the "too many levels of symbolic links", because the link failed the symlink ends up pointing to itself. Neale On Feb 3, 2014, at 7:08 PM, Christian Thalinger wrote:

I haven’t tried LLVM 3.4 yet (compiling it right now) but it seems some method signatures have changed. Let’s see if I can make it work...

On Feb 3, 2014, at 11:50 AM, Neale Ferguson <neale at sinenomine.net> wrote:

Hi, I'm attempting build openJDK7 with SHARK/ZERO and am encountering the following when using llvm-3.4:

In file included from /home/neale/openjdk7/hotspot/src/share/vm/shark/llvmValue.hpp:30, from /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkBlock.cpp:29: /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp: In member function 'llvm::Constant* SharkContext::getexternal(const char*, const llvm::FunctionType*)': /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: invalid conversion from 'const llvm::FunctionType*' to 'llvm::FunctionType*' /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: initializing argument 2 of 'llvm::Constant* llvm::Module::getOrInsertFunction(llvm::StringRef, llvm::FunctionType*)' line 72 looks like: llvm::Constant* getexternal(const char* name, const llvm::FunctionType* sig) { return module()->getOrInsertFunction(name, sig); } Before I go too far with this I thought I'd find out if this was a known issue. I note there were other issues getting this far, like where 3.4 keeps its include files (in /usr/include/llvm/IR/...) so there are probably other changes of significance. Neale

More information about the hotspot-dev mailing list