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

Andrew Hughes gnu.andrew at redhat.com
Thu Feb 6 14:46:51 PST 2014

----- Original Message -----

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

On Feb 5, 2014, at 8:30 PM, Neale Ferguson <neale at sinenomine.net> wrote: > I simply followed the instructions and did a hg clone and then used the > getsource script to populate everything. > > I did find a patch that removed generatestubs 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. >

The obvious thing that occurs to me is that:

8003868: fix shark for latest HotSpot and LLVM Reviewed-by: twisti Contributed-by: Roman Kennke <rkennke at redhat.com>

is only present in 8 and not 7u. That added support for LLVM 3.3 IIRC.

There were also Makefile changes required for Zero that probably apply to Shark too:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012451.html

(notably gcc.make has conditionals on Shark but doesn't bring in defs.make where they are set)

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

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

More information about the hotspot-dev mailing list