FW: Porting OpenJDK 6 to Stratus OpenVOS on IA32 -- OpenVOSfunction pointers not the same as code pointers

[Barnes, Richard]

Hi Gary,

That is indeed the way I decided to proceed last Friday.  I will be
adding some code that will only run on our OS that will make sure that
the value is treated as a function pointer.

Thanks for your confirmation.

Richard

-----Original Message-----
From: Gary Benson [mailto:gbenson at redhat.com] 
Sent: Monday, December 15, 2008 4:16 AM
To: Barnes, Richard
Cc: porters-dev at openjdk.java.net; Joe.Darcy at Sun.COM
Subject: Re: FW: Porting OpenJDK 6 to Stratus OpenVOS on IA32 --
OpenVOSfunction pointers not the same as code pointers

Hi Richard,

I *think* Address(method, methodOopDesc::native_function_offset())
will return whatever your operating system things is a function
pointer, ie it will return a pointer to the descriptor rather than
the code pointer.  That's certainly how it works on ppc64, which
has a similar system.  But just try it; if it crashes then maybe
try it the other way ;)

Cheers,
Gary

Barnes, Richard wrote:
> One of the problems we have run into is that on most platforms a
> function pointer contains the address of the entrypoint of the
> function.  That is, it is literally a pointer to the code.  With
> OpenVOS, like on PA-RISC and IA64, a function pointer is a pointer
> to a two-word descriptor -- one word pointing to the code and the
> other pointing to data (think of this as a pointer to the global
> offset table or a pointer to thread-local storage).
> 
> The HotSpot code we have seen does not seem to be prepared for this
> difference in what a function pointer is.  Consider the macros
> CAST_FROM_FN_PTR and CAST_TO_FN_PTR in
> src/share/vm/utilities/globalDefinitions.hpp, where it is obvious
> that a function pointer is supposed to be a direct pointer to the
> entry point.  This is causing us confusion in what we might have to
> do to make native calls work, such as in
> src/cpu/i486//vm/interpreter_i486.cpp's
> InterpreterGenerator::generate_native_entry() method.  What we do
> not know is whether Address(method,
> methodOopDesc::native_function_offset()) is going to return a
> function pointer or a pointer to the code.  While this wouldn't
> matter for most platforms, it does matter for ours.
> 
> Does anybody have any experience with this kind of problem?
> 
> Thanks,
> 
> Richard Barnes
> Senior Technical Consultant
> Stratus Technologies
> 
> > ______________________________________________ 
> > From: 	Barnes, Richard  
> > Sent:	Friday, September 12, 2008 4:31 PM
> > To:	'porters-dev at openjdk.java.net'
> > Cc:	'Joe.Darcy at Sun.COM'; Richard Barnes
> > Subject:	Porting OpenJDK 6 to Stratus OpenVOS on IA32
> > 
> > I am part of a small team at Stratus Technologies that is planning
> > to port OpenJDK6 to its proprietary OpenVOS operating system
> > running on IA32.  What makes this interesting and unusual is that
> > even though we are targeting a little-endian chip, for
> > compatibility reasons OpenVOS must present a big-endian
> > environment to its users, so that gcc and g++, as well as native
> > OpenVOS compilers, produce code that makes IA32 appear to be
> > big-endian at the source level.  The internals of OpenVOS are
> > quite different from the internals of Unix, but we have added a
> > POSIX.1 API to our operating system in recent years, which should
> > help to make this project possible.  The runtime conventions are
> > close to those of Unix on IA32, with the exception of endianness
> > and some register usage, but that should not be insurmountable.
> > 
> > When I first sent mail to jdk-6.dev, Joe Darcy of Sun suggested
> > that we check in with this group for community advice.
> > 
> > For these reasons, we hope to have our project accepted to join
> > OpenJDK.
> > 
> > Thanks,
> > 
> > Richard Barnes
> > Senior Technical Consultant
> > Stratus Technologies

-- 
http://gbenson.net/