FW: Porting OpenJDK 6 to Stratus OpenVOS on IA32 -- %EBP and the HotSpot server compiler

[Barnes, Richard]

There is a comment in
hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86CurrentFr
ameGuess.java that says that EBP is not guaranteed to be valid for
compiled code.  In the context of this code that fact is considered a
nuisance for debugging, but not a show-stopper.

For OpenVOS, this fact could cause real problems in that our stack
conventions require that at least one of two conditions for all code
being executed is true:

*	%EBP is the frame pointer for the current stack frame or the
code for this procedure must not have modified %EBP.

*	The code must be covered by what we call a block_map and
entry_block that describes how the size of the stack frame for the code
is calculated.  (This allows us to use %EBP as something other than a
frame pointer unless the frame size is variable.)

I am assuming that it is probably too hard to get the server compiler to
generate a block_map and entry_block, which we did get GCC to do,  So,
what we are wondering is whether there might be an easy way to get the
server compiler to either use %EBP as a frame pointer or to not modify
it at all.  I note that both GCC and our native OpenVOS compilers have
both internal and external switches that allow us to do just that.  If
no such switch exists, would there be a way to modify the server
compiler or a table it uses to get the behavior we desire?

If not, is there any reliable way we can walk the stack without these
changes?

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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20091203/10a785a6/attachment.html