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

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Fri Feb 7 07:02:18 PST 2014

Hi Neale,

it should be hg repositories. You have to go into /hotspot, in there hg diff should work.

The get_source script pulls several independent hg repositories into the main you already pulled.

Best regards, Goetz.

-----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Neale Ferguson Sent: Freitag, 7. Februar 2014 15:52 To: Christian Thalinger Cc: hotspot-dev at openjdk.java.net Subject: Re: Error building hotspot with shark/zero

I had intended sending the diffs, but didn't realize that when get_source.sh is executed it just sucks in the source files and doesn't use hg to get them. I had envisaged just doing a hg diff to get the patchset but now I'll have to go and do it manually. It may take some time as I have to do some work on the LLVM SystemZ JIT.

Neale

On Feb 6, 2014, at 4:48 PM, Christian Thalinger wrote:

Can you talk to Andrew (CCed) about integrating your changes?

On Feb 5, 2014, at 8:30 PM, Neale Ferguson <neale at sinenomine.net<mailto:neale at sinenomine.net>> wrote:

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<mailto: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<mailto: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<mailto: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