Recent HotSpot changes in OpenJDK break Mac OS X

[Xiaobin Lu]

Hi Greg,

You probably need to join bsd-port-dev at openjdk.java.net alias if you 
haven't. And then you can open the email archive to see more on the 
thing you discovered below. 

Regards,
-Xiaobin

Greg Lewis wrote:
> G'day all,
>
> I'm working on the BSD port of OpenJDK and we recently merged in HotSpot
> changes that have broken the build on Mac OS X.
>
> The breakage looks like this:
>
> /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp:
> In member function 'void InterpreterMacroAssembler::empty_expression_stack()':
> /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp:123:
> error: call of overloaded 'movptr(Address, int)' is ambiguous
> /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2010:
> note: candidates are: void MacroAssembler::movptr(Address, intptr_t)
> /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2012:
> note:                 void MacroAssembler::movptr(Address, RegisterImpl*)
> make[6]: *** [incls/_precompiled.incl.gch] Error 1
>
> The guilty line of code in interp_masm_x86_32.hpp is this one:
>
>       // NULL last_sp until next java call
>       movptr(Address(rbp, frame::interpreter_frame_last_sp_offset * wordSize), (int32_t)NULL_WORD);
>
> There are many other similar instances though, thats just the first one the
> compiler encounters.
>
> The prototypes in assember_x86.hpp are:
>
>   void movptr(Address dst, intptr_t src);
>   void movptr(Address dst, Register src);
>
> Note that Mac OS X is not LP64, so the additional prototype for movptr
> that takes an int32_t as the second parameter doesn't get defined (and it
> wouldn't be helpful anyway since that definition is specifically for 64 bit
> x86 OSes).
>
> The code is basically relying on int32_t and intptr_t being typedef'ed to
> the same thing on 32 bit platforms.  However, there is no language standard
> I'm aware of that guarantees this.  On FreeBSD and Linux they are both
> typedef'ed to an int, so this works.  I suspect the same is true on Solaris
> although I haven't got a box I can check that on.  However, on Mac OS X
> int32_t is typedef'ed as an int and intptr_t is typedef'ed as a long, hence
> the above error.
>
> This could be "fixed" with a Mac OS X specific definition that takes an
> int32_t, but thats just papering over the broken assumption in the code.
> I'd also like to avoid littering the code with #ifdef's that call the
> int32_t version on LP64 and the intptr_t version otherwise.  Another way
> would be something like this:
>
> #ifdef _LP64
> #define 32BIT_MOVPTR_CAST_TYPE int32_t
> #else
> #define 32BIT_MOVPTR_CAST_TYPE intptr_t
> #endif
>
> and then cast to (32BIT_MOVPTR_CAST_TYPE).  That still seems hacky though,
> and introduces a lot of gratuitous changes into the BSD port which will
> make merging harder.
>
> Can anyone think of a more general solution that doesn't undo the merge of
> the 32 and 64 bit code that appears to be responsible for this?
>
>