United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7171653 32-bit cross-compile on 64-bit build host generates 64-bit data for awt/X11 leading to crash
JDK-7171653 : 32-bit cross-compile on 64-bit build host generates 64-bit data for awt/X11 leading to crash

Details
Type:
Bug
Submit Date:
2012-05-24
Status:
Resolved
Updated Date:
2014-02-05
Project Name:
JDK
Resolved Date:
2012-05-30
Component:
infrastructure
OS:
generic
Sub-Component:
build
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
8
Fixed Versions:

Related Reports
Backport:
Relates:

Sub Tasks

Description
The JDK build system is not currently set up to allow 32-bit builds on 64-bit build hosts - see 7153072. This also impacts a 32-bit cross-compilation build on a 64-bit build host. The problem is in the sun/xawt/Makefile where we compile and run the "sizers" program that generates the sizes.32 or sizes.64 data file for use by the Xawt code. Based on ARCH_DATA_MODEL the logic correctly determines whether it is building sizesr.32.c or sizers.64.c, and generates sizes.32 or sizes.64 accordingly. However sizers.c is compiled with the HOST_CC command and will be built using the default data model for the host compiler. So on 64-bit sizers.c.32 gets built as a 64-bit program and when run produces 64-bit values into the sizes.32 file eg:

 > more gensrc/sun/awt/X11/generator/sizes.32
long    8
int     4
short   2
ptr     8
Bool    4
Atom    8
Window  8

instead of

long    4
int     4
short   2
ptr     4
Bool    4
Atom    4
Window  4

These incorrect sizes cause incorrect address calculations to be used which typically leads to a SEGV

>>> Problem is coming from XToolkit.setupModifiers:
>>>
>>> 1741 try {
>>> 1742 XModifierKeymap modmap = new XModifierKeymap(
>>> 1743 XlibWrapper.XGetModifierMapping(getDisplay()));
>>> 1744
>>> 1745 int nkeys = modmap.get_max_keypermod();
>>> 1746
>>> 1747 long map_ptr = modmap.get_modifiermap();
>>>
>>> map_ptr is invalid address and gets passed to Native.getUbyte, which passes it to
>>> sun.misc.Unsafe.getByte - hence the SEGV.

Any use of the HOST_CC command is potentially at risk here but fortunately this is the only case used when cross-compiling (the other case - in the NIO generators - is skipped when cross-compiling).

                                    

Comments
SUGGESTED FIX

diff -r 5bf0eb7c560c make/sun/xawt/Makefile
--- a/make/sun/xawt/Makefile
+++ b/make/sun/xawt/Makefile
@@ -276,7 +276,12 @@
 ifndef CROSS_COMPILE_ARCH
        $(CC) $(CFLAGS_$(subst .,,$(suffix $@))) $(CPPFLAGS) -o $@ $(SIZER)$(suffix $@).c
 else
-       $(HOST_CC) $(CPPFLAGS) -o $@ $(SIZER)$(suffix $@).c
+  ifeq ($(ARCH_DATA_MODEL),32)
+    CC_DATA_MODEL=-m32
+  else
+    CC_DATA_MODEL=-m64
+  endif
+       $(HOST_CC) $(CC_DATA_MODEL) $(CPPFLAGS) -o $@ $(SIZER)$(suffix $@).c
 endif

When 7153072 is fixed the -m32/-m64 should already be part of the CPPFLAGS and this workaround should not be needed.
                                     
2012-05-24
EVALUATION

See description and suggested fix
                                     
2012-05-24
SUGGESTED FIX

A cleaner fix is to use the CFLAGS_32 and CFLAGS_64 variables to pass -m32/-m64 when cross-compiling.
                                     
2012-05-25
EVALUATION

http://hg.openjdk.java.net/jdk8/build/jdk/rev/8b4dd321b8a2
                                     
2012-05-30



Hardware and Software, Engineered to Work Together