RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling
david.holmes at oracle.com
Mon Nov 30 04:23:52 UTC 2015
Trying to trace through this is somewhat complex :)
At the top level if we see ppc64le then we set VAR_CPU to ppc64le
instead of ppc64. However, once we get into hotspot build we want ARCH
to be ppc64 again (in hotspot-spec.gmk.in) - why is that?
Inside hotpot we want:
SRCARCH := ppc
BUILDARCH := ppc64
LIBARCH := ppc64le
right? So can ARCH not be ppc64le from the top-level and then we adjust
SRCARCH and BUILDARCH? And avoid the top-level changes to ARCH.
More comments below ...
On 30/11/2015 12:39 PM, Alexander Smundak wrote:
> Please review the patch set that fixes
> https://bugs.openjdk.java.net/browse/JDK-8073139: PPC64: User-visible
> arch directory and os.arch value on ppc64le cause issues with Java
Is it not the case that ppc64le -> ppc64, so that we can avoid "if
defined(ppc64) | defined(ppc64le) ? I would hope that the only places in
the sources where you need to check for ppc64le is where that code
differs from the ppc64 code.
See above discussion re ARCH etc.
I think this messy code block relates to builds where CPU is not set -
which should never be the case these days. Maybe just put in a check
"ifndef CPU -> error" ?
Again referring back to earlier ARCH discussion, I don't like seeing the
platform specific code in hotspot-spec.gmk.in.
> The patch is based on the patch by Andrew Hughes (gnu.andrew at redhat.com),
> please see the thread
> The current patch set adds the changes to show the correct architecture in the
> 'java -Xinternalversion' output and test_env.sh (both pointed by
> goetz.lindenmaier at sap.com), and fixes Serviceability Agent and
> disassembler (hsdis).
> I need a sponsor.
More information about the hotspot-dev