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