Mac OS X i486 ABI -- 16-byte stack alignment
Landon Fuller
landonf at threerings.net
Wed Nov 7 14:04:56 PST 2007
I've been working on getting the JDK running on Mac OS X Leopard /
x86, based on the BSD's JDK16 porting work -- so far I've gotten
'Hello World' running, while anything more complex quickly runs into
stack alignment issues -- Mac OS X's x86 calling conventions require
a 16-byte aligned stack pointer at function entry.
The first issue I've hit is alignment in the
MacroAssembler::call_VM_base() code generation. It doesn't look like
I can determine the current stack alignment within the call_VM()
methods, and there's no gaurantee that the frame started 16-byte
aligned, either. Given that, I was thinking that doing an alignment
fixup in call_VM_base() might be a workable solution -- something like:
/* Arguments */
int argSize = arg_count * wordSize;
pushl %esi ; save %esi, we'll use it to store the current sp
movl %esp, %esi
andl $-16, %esp ; force sp to a known (16-byte) alignment
if (argSize & 15) {
// Pad SP for alignment if the pushed args aren't going to leave us
16-byte aligned
subl $((argSize + 15) & -16) - argSize, %esp;
}
... push arguments ...
call
movl %esi, %esp ; restore pre-alignment sp
popl %esi ; restore esi
However, this means that call_VM_base() needs to push the arguments
on to the stack itself, rather than relying on the call_VM()
implementations to do so. Thus, I was thinking about modifying
call_VM_base() to accept an arg array:
virtual void call_VM_base( // returns the register
containing the thread upon return
Register oop_result, // where an oop-result ends
up if any; use noreg otherwise
Register java_thread, // the thread if computed
before ; use noreg otherwise
Register last_java_sp, // to set up last_Java_frame
in stubs; use noreg otherwise
address entry_point, // the entry point
int number_of_arguments, // the number of arguments (w/
o thread) to pop after the call
Register args[], // call arguments, left-to-
right ordered <-- NEW ARGUMENT
bool check_exceptions // whether to check for
pending exceptions after return
);
That way, call_VM can fixup the alignment, push the args, do the
call, and restore esp.
Thoughts, criticism, and suggestions are very much appreciated, as
are suggestions on where else I should be worrying about stack
alignment. This is the first I've looked at the hotspot code, so
hopefully my evaluation is not completely off in the weeds.
Thanks!
-landonf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071107/61a00eb1/attachment.bin
More information about the hotspot-dev
mailing list