Mac OS X i486 ABI -- 16-byte stack alignment

[Paul Hohensee]

Take a look at the x64 code.  The x64 ABI requires 16-byte alignment at
call sites.  Compiler-generated code maintains 16-byte alignment at all
times, but the template interpreter doesn't, so calling out from it means
aligning the stack.

See, e.g., call_VM_base in assembler_x86_64.cpp.

Paul

Landon Fuller wrote:
> 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