Error building hotspot with shark/zero

[Andrew Hughes]

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

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...
> > > sharedRuntime_zero.o: In function `SharedRuntime::generate_stubs()':
> > > sharedRuntime_zero.cpp:(.text+0x3bc): multiple definition of
> > > `SharedRuntime::generate_stubs()'
> > > sharedRuntime.o:sharedRuntime.cpp:(.text+0x1328): first defined here
> > > sharedRuntime_zero.o:(.bss+0x18): multiple definition of
> > > `SharedRuntime::_wrong_method_blob'
> > > sharedRuntime.o:(.bss+0x0): first defined here
> > > sharedRuntime_zero.o:(.bss+0x20): multiple definition of
> > > `SharedRuntime::_ic_miss_blob'
> > > sharedRuntime.o:(.bss+0x8): first defined here
> > > sharedRuntime_zero.o:(.bss+0x28): multiple definition of
> > > `SharedRuntime::_resolve_opt_virtual_call_blob'
> > > sharedRuntime.o:(.bss+0x10): first defined here
> > > sharedRuntime_zero.o:(.bss+0x30): multiple definition of
> > > `SharedRuntime::_resolve_virtual_call_blob'
> > > sharedRuntime.o:(.bss+0x18): first defined here
> > > sharedRuntime_zero.o:(.bss+0x38): multiple definition of
> > > `SharedRuntime::_resolve_static_call_blob'
> > > sharedRuntime.o:(.bss+0x20): first defined
> > > heresharedRuntime_zero.o:(.bss+0x8): multiple definition of
> > > `SharedRuntime::_polling_page_safepoint_handler_blob'sharedRuntime.o:(.bss+0x38):
> > > first defined heresharedRuntime_zero.o:(.bss+0x10): multiple definition
> > > of
> > > `SharedRuntime::_polling_page_return_handler_blob'sharedRuntime.o:(.bss+0x40):
> > > first defined heresharedRuntime_zero.o:(.bss+0x0): multiple definition
> > > of `SharedRuntime::_deopt_blob'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 sharedRuntime_zero.cpp have generate_stubs
> > > 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::get_external(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* get_external(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