[oi-dev] Building openjdk-8-162 with gcc-6 on SPARC

Michal Nowak mnowak at startmail.com
Sun Jan 12 16:00:10 UTC 2020


On 01/12/20 04:03 PM, Gary Mills wrote:
> I'm attempting to build openjdk-8-162 with gcc-6 on SPARC hardware.  I
> finally got a successful gmake build, but a failure with gmake
> install.  The error was this one:
> 
>      Error occurred during initialization of VM
>      java.lang.StackOverflowError
>              at java.lang.Object.<clinit>(Object.java:41)
> 
> All newly-build java applications produce the same error.  With a
> search on the web, I found exactly the same error for linux.  The bug
> apparently affected all architectures except x86.  It appeared because
> of increased optimization in later versions of gcc.  This is the linux
> patch:
> 
> diff --git a/src/os_cpu/linux_zero/vm/os_linux_zero.cpp b/src/os_cpu/linux_zero/vm/os_linux_zero.cpp
> --- jdk8/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.cpp
> +++ jdk8/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.cpp
> @@ -55,8 +55,8 @@
>   #include "utilities/vmError.hpp"
>   
>   address os::current_stack_pointer() {
> -  address dummy = (address) &dummy;
> -  return dummy;
> +  // return the address of the current function
> +  return (address)__builtin_frame_address(0);
>   }
>   
>   frame os::get_sender_for_C_frame(frame* fr) {
> 
> This, of course, has no effect on OI.  During the build, OI is
> detected as solaris.  The equivalent function for solaris-sparc, in
> openjdk/hotspot/src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp,
> has this code:
> 
>      address os::current_stack_pointer() {
>        volatile int dummy;
>        address sp = (address)&dummy + 8;     // %%%% need to confirm if this is right
>        return sp;
>      }
> 
> I assume that it's also compiled incorrectly because of the increased
> optimization, but I don't know how to correct it.  I'm also concerned
> about the comment.  Is it right?
> 
> Has anybody else built openjdk for SPARC with gcc?  How did you fix
> this bug?
> 
> 

Does building with lesser optimization level than the present one make 
the problem go away? Look for 'gcc_OPT' in make-rules/shared-macros.mk 
and use it in the component's Makefile.

Michal




More information about the oi-dev mailing list