RFR: 8073139 PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling

David Holmes david.holmes at oracle.com
Mon Nov 30 04:23:52 UTC 2015

Hi Sasha,

Trying to trace through this is somewhat complex :)

So ...

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
> tooling:
> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.02


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" ?

> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.02

No comments.

> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.02

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
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-February/017148.html
> 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.
> Sasha

More information about the hotspot-dev mailing list