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

Ioi Lam ioi.lam at oracle.com
Fri Nov 15 18:46:04 UTC 2019


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