Build broken for ARM32 after 8231610: Relocate the CDS archive if it cannot be mapped to the requested address

christoph.goettschkes at microdoc.com christoph.goettschkes at microdoc.com
Mon Nov 18 08:36:39 UTC 2019


thanks for looking into this. I will then create a new issue in the JBS 
and make an RFR for it.

-- Christoph

"hotspot-runtime-dev" <hotspot-runtime-dev-bounces at openjdk.java.net> wrote 
on 2019-11-15 19:46:04:

> From: Ioi Lam <ioi.lam at oracle.com>
> To: hotspot-runtime-dev at openjdk.java.net
> Date: 2019-11-15 19:46
> Subject: Re: Build broken for ARM32 after 8231610: Relocate the CDS 
> archive if it cannot be mapped to the requested address
> Sent by: "hotspot-runtime-dev" 
<hotspot-runtime-dev-bounces at openjdk.java.net>
> 
> Hi Christoph,
> 
> The changes look good to me. I tried them on Linux/x64 and they will be 
> triggered if muck with the value:
> 
>        _mapping_offset = 
(size_t)CompressedOops::encode_not_null((oop)base);
>        if (crc != 0) {
>          _mapping_offset += 0x100000000;
>        }
>        assert(_mapping_offset == (size_t)(uint32_t)_mapping_offset, 
> "must be 32-bit only");
> 
> We also have similar checks elsewhere in the VM:
> 
> ./cpu/x86/nativeInst_x86.cpp:  guarantee(disp == 
> (intptr_t)(int32_t)disp, "must be 32-bit offset");
> 
> Thanks
> - Ioi
> 
> 
> On 11/15/19 5:49 AM, christoph.goettschkes at microdoc.com wrote:
> > Hi,
> >
> > I am no longer able to build for ARM32 after the commit for 8231610:
> > Relocate the CDS archive if it cannot be mapped to the requested 
address
> > [1]. I am using a linaro toolchain with a GCC version 4.9.4.
> >
> > arm-linux-gnueabi-g++ (Linaro GCC 4.9-2017.01) 4.9.4
> > Copyright (C) 2015 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There 
is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> >
> > src/hotspot/share/memory/filemap.cpp:1569:21:
> > error: right shift count >= width of type [-Werror]
> >     assert((offset >> 32) == 0, "must be 32-bit only");
> >
> > I guess the same check could be achieved without a right shift 
operation,
> > by casting the offset twice and comparing it?
> >     assert(offset == (size_t)(uint32_t)offset, "must be 32-bit only");
> >
> > Here is a webrev [2] for that particular fix (there are two instances
> > where size_t is right shifted by 32). Should I open a new bug for 
this,
> > or should this be discussed using the already existing bug 8231610?
> >
> > -- Christoph
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8231610
> > [2] https://cr.openjdk.java.net/~cgo/8231610/webrev.00/
> >
> 



More information about the hotspot-runtime-dev mailing list