Merging BSDPort into HotSpot mainline

[Kurt Miller]

On Tuesday 09 August 2011 10:04:44 pm Tom Rodriguez wrote:
> 
> > 
> >> src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:
> >> src/cpu/x86/vm/interp_masm_x86_32.cpp:
> >> 
> >> Why is the change of the cast needed?  That idiom is used in many other places that haven't been modified.  It's an odd little idiom that could be eliminated by fixing a limitation in the MacroAssembler where it emits larger assembly than it needs to.  Mainly I'm just unclear why it was changed in some places and not others.
> > 
> > On OpenBSD/i386 and I believe also OS/X/x86_32 intptr_t is typedef to long not int which leads to the following build errors:
> > 
> > g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 -DPRODUCT -I. -I/home/truk/jdk/bsd-port/hotspot/src/share/vm/prims -I/home/truk/jdk/bsd-port/hotspot/src/share/vm -I/home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm -I/home/truk/jdk/bsd-port/hotspot/src/os_cpu/bsd_x86/vm -I/home/truk/jdk/bsd-port/hotspot/src/os/bsd/vm -I/home/truk/jdk/bsd-port/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"21.0-b17\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"truk\"" -DHOTSPOT_LIB_ARCH=\"i386\" -DJRE_RELEASE_VERSION="\"1.7.0-internal-truk_2011_08_02_14_13-b00\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DDEFAULT_LIBPATH="\"/usr/lib:/usr/X11R6/lib:/usr/local/lib\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_32 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_32 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m32 -march=i586 -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -Werror -Wpointer-arith -Wconversion -Wsign-compare    -c -MMD -MP -MF ../generated/dependencies/c1_LIRAssembler_x86.o.d -o c1_LIRAssembler_x86.o /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
> > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: In member function 'int LIR_Assembler::emit_unwind_handler()':
> > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:483: error: call of overloaded 'movptr(Address, int32_t)' is ambiguous
> > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2317: note: candidates are: void MacroAssembler::movptr(Address, intptr_t)
> > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2319: note:                 void MacroAssembler::movptr(Address, RegisterImpl*)
> > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:484: error: call of overloaded 'movptr(Address, int32_t)' is ambiguous
> > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2317: note: candidates are: void MacroAssembler::movptr(Address, intptr_t)
> > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2319: note:                 void MacroAssembler::movptr(Address, RegisterImpl*)
> 
> I looked at this again and realized that this was the only case of this idiom in 32 bit.  All the others are in 64 bit which explains why only this one was needed but not the others.  I think the history of it is that the MacroAssembler isn't doing a very good job of selecting shorter instruction formats when the value is declared intptr_t but the actual value fits in 32 or 8 bits.  The change itself is ok.

Great.

> > +
> > +#if defined(__OpenBSD__)
> > +    // Work-around OpenBSD's lack of $ORIGIN support by pre-loading libnet.so
> > +    // ignore errors
> > +    dll_build_name(buffer, sizeof(buffer), Arguments::get_dll_dir(), "net");
> > +    dll_load(buffer, ebuf, sizeof(ebuf));
> > +#endif
> > 
> > This one is due to OpenBSD's lack of $ORIGIN support in our runtime linker. I've been meaning to add support for it, but have been short on time. Clearly it is a hack but it is needed for OpenBSD until $ORIGIN is supported.
> 
> Yes, this is the one I meant.  Why is this hack in the JVM instead of the JDK?  Aren't you likely to hit other problems than just this?

Indeed it is not a complete work-around. For example using JDWP requires setting LD_LIBRARY_PATH. I'm ok with this hunk not making it into hotspot. It will provide me the incentive to write $ORIGIN support for OpenBSD's runtime linker. :-)

> > 
> >> 
> >> I see a full copy of elf.h in there as well which I doubt we can accept.  It seems to be apple specfic but doesn't mac use MachO?  
> >> 
> > 
> > This was brought in for Apple support. We need an Apple developer to remove it and find the places where the build is missing defines. I don't have an x86 OS/X box at the moment to do this work.
> 
> I grabbed the patch and tried to build it on my mac.  It immediately failed trying to build sa-jdi.jar since the standard Mac jdk doesn't have a separate tools.jar, which I guess is expected.  The other problems I see are format mismatches in memprofiler.cpp and os.cpp that I think are fixed in the macosx-port repo with some more format changes.  I assume that can be dealt with when those changes come in though.
> 
> I made a patch that removes the usages of elf.h on Mac.  I uploaded it as http://cr.openjdk.java.net/~never/elf.  It compiles and builds on my Snow Leopard mac though I had to massage the build a little bit extra to deal with the previously mentioned format issues.

Great. Thank you.

What is the next step to move this forward?

Regards,
-Kurt