[RFA Darwin]: Add push_dummy_call for i386

[RFA Darwin]: Add push_dummy_call for i386

[Tristan Gingold]

Hi,

Darwin i386 ABI is slightly different from the SVR4 one.  In particular
stack alignment is 16.  As a consquence, i386 Darwin can't use the standard
i386-tdeo.c push_dummy_call and this patch provides a Darwin version of this
call.

Regtested on i386 Darwin.
Tristan.


2009-07-03  Tristan Gingold  <gingold@adacore.com>

	* i386-darwin-tdep.c (i386_m128_p): New function.
	(i386_darwin_arg_type_alignment): Ditto.
	(i386_darwin_push_dummy_call): Ditto.
	(i386_darwin_init_abi): Define Darwin specific push_dummy_call.
	Adjust long_double size.  Adjust pc offset in setjump buffer.

Index: i386-darwin-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-darwin-tdep.c,v
retrieving revision 1.6
diff -c -p -r1.6 i386-darwin-tdep.c
*** i386-darwin-tdep.c	3 Jul 2009 12:06:36 -0000	1.6
--- i386-darwin-tdep.c	3 Jul 2009 15:48:55 -0000
*************** darwin_dwarf_signal_frame_p (struct gdba
*** 109,114 ****
--- 109,241 ----
   return i386_sigtramp_p (this_frame);
 }

+ /* Check wether TYPE is a 128-bit vector (__m128, __m128d or __m128i).  */
+ 
+ static inline int
+ i386_m128_p (struct type *type)
+ {
+   return TYPE_CODE (type) == TYPE_CODE_ARRAY && TYPE_VECTOR (type)
+     && TYPE_LENGTH (type) == 16;
+ }
+ 
+ /* Check whether TYPE must be 16-byte-aligned when passed as a
+    function argument.  16-byte vectors, _Decimal128 and structures or
+    unions containing such types must be 16-byte-aligned; other
+    arguments are 4-byte-aligned.  */
+ 
+ static int
+ i386_darwin_arg_type_alignment (struct type *type)
+ {
+   type = check_typedef (type);
+   /* Passing arguments.
+      5.  The caller places 64-bit vectors (__m64) on the parameter area,
+          aligned to 8-byte boundaries.
+      6.  [...]  The caller aligns 128-bit vectors in the parameter area to
+          16-byte boundaries.  */
+   if (TYPE_CODE (type) == TYPE_CODE_ARRAY && TYPE_VECTOR (type))
+     return TYPE_LENGTH (type);
+   /* 2.  The caller aligns nonvector arguments to 4-byte boundaries.  */
+   return 4;
+ }
+ 
+ static CORE_ADDR
+ i386_darwin_push_dummy_call (struct gdbarch *gdbarch, struct value *function,
+ 			     struct regcache *regcache, CORE_ADDR bp_addr,
+ 			     int nargs, struct value **args, CORE_ADDR sp,
+ 			     int struct_return, CORE_ADDR struct_addr)
+ {
+   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+   enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
+   gdb_byte buf[4];
+   int i;
+   int write_pass;
+ 
+   /* Determine the total space required for arguments and struct
+      return address in a first pass (allowing for 16-byte-aligned
+      arguments), then push arguments in a second pass.  */
+ 
+   for (write_pass = 0; write_pass < 2; write_pass++)
+     {
+       int args_space = 0;
+       int nbr_m128 = 0;
+ 
+       if (struct_return)
+ 	{
+ 	  if (write_pass)
+ 	    {
+ 	      /* Push value address.  */
+ 	      store_unsigned_integer (buf, 4, byte_order, struct_addr);
+ 	      write_memory (sp, buf, 4);
+ 	    }
+           args_space += 4;
+ 	}
+ 
+       for (i = 0; i < nargs; i++)
+ 	{
+           struct type *arg_type = value_enclosing_type (args[i]);
+ 
+           if (i386_m128_p (arg_type) && nbr_m128 < 4)
+             {
+               if (write_pass)
+                 {
+                   const gdb_byte *val = value_contents_all (args[i]);
+                   regcache_raw_write
+                     (regcache, I387_MM0_REGNUM(tdep) + nbr_m128, val);
+                 }
+               nbr_m128++;
+             }
+           else
+             {
+               int len = TYPE_LENGTH (arg_type);
+               int align = i386_darwin_arg_type_alignment (arg_type);
+ 
+               args_space = align_up (args_space, align);
+               if (write_pass)
+                 write_memory (sp + args_space,
+                               value_contents_all (args[i]), len);
+ 
+               /* The System V ABI says that:
+                  
+                  "An argument's size is increased, if necessary, to make it a
+                  multiple of [32-bit] words.  This may require tail padding,
+                  depending on the size of the argument."
+                  
+                  This makes sure the stack stays word-aligned.  */
+               args_space += align_up (len, 4);
+             }
+         }
+ 
+       /* Darwin i386 ABI:
+ 	 1.  The caller ensures that the stack is 16-byte aligned at the point
+ 	 of the function call.  */
+       if (!write_pass)
+ 	sp = align_down (sp - args_space, 16);
+     }
+ 
+   /* Store return address.  */
+   sp -= 4;
+   store_unsigned_integer (buf, 4, byte_order, bp_addr);
+   write_memory (sp, buf, 4);
+ 
+   /* Finally, update the stack pointer...  */
+   store_unsigned_integer (buf, 4, byte_order, sp);
+   regcache_cooked_write (regcache, I386_ESP_REGNUM, buf);
+ 
+   /* ...and fake a frame pointer.  */
+   regcache_cooked_write (regcache, I386_EBP_REGNUM, buf);
+ 
+   /* MarkK wrote: This "+ 8" is all over the place:
+      (i386_frame_this_id, i386_sigtramp_frame_this_id,
+      i386_dummy_id).  It's there, since all frame unwinders for
+      a given target have to agree (within a certain margin) on the
+      definition of the stack address of a frame.  Otherwise frame id
+      comparison might not work correctly.  Since DWARF2/GCC uses the
+      stack address *before* the function call as a frame's CFA.  On
+      the i386, when %ebp is used as a frame pointer, the offset
+      between the contents %ebp and the CFA as defined by GCC.  */
+   return sp + 8;
+ }
+ 
 static void
 i386_darwin_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
 {
*************** i386_darwin_init_abi (struct gdbarch_inf
*** 119,124 ****
--- 246,252 ----
   set_gdbarch_num_regs (gdbarch, I386_SSE_NUM_REGS);

   dwarf2_frame_set_signal_frame_p (gdbarch, darwin_dwarf_signal_frame_p);
+   set_gdbarch_push_dummy_call (gdbarch, i386_darwin_push_dummy_call);

   tdep->struct_return = reg_struct_return;

*************** i386_darwin_init_abi (struct gdbarch_inf
*** 127,133 ****
   tdep->sc_reg_offset = i386_darwin_thread_state_reg_offset;
   tdep->sc_num_regs = i386_darwin_thread_state_num_regs;

!   tdep->jb_pc_offset = 20;

   set_solib_ops (gdbarch, &darwin_so_ops);
 }
--- 255,266 ----
   tdep->sc_reg_offset = i386_darwin_thread_state_reg_offset;
   tdep->sc_num_regs = i386_darwin_thread_state_num_regs;

!   tdep->jb_pc_offset = 48;
! 
!   /* Although the i387 extended floating-point has only 80 significant
!      bits, a `long double' actually takes up 128, probably to enforce
!      alignment.  */
!   set_gdbarch_long_double_bit (gdbarch, 128);

   set_solib_ops (gdbarch, &darwin_so_ops);
 }

Re: [RFA Darwin]: Add push_dummy_call for i386

[Mark Kettenis]

> Date: Fri, 3 Jul 2009 17:51:52 +0200
> From: Tristan Gingold <gingold@adacore.com>
> 
> Hi,
> 
> Darwin i386 ABI is slightly different from the SVR4 one.  In particular
> stack alignment is 16.  As a consquence, i386 Darwin can't use the standard
> i386-tdeo.c push_dummy_call and this patch provides a Darwin version of this
> call.
> 
> Regtested on i386 Darwin.
> Tristan.

Tristan, can you provide unified diffs instead of context diffs?  It's much easier to read the unified ones.

> 2009-07-03  Tristan Gingold  <gingold@adacore.com>
> 
> 	* i386-darwin-tdep.c (i386_m128_p): New function.
> 	(i386_darwin_arg_type_alignment): Ditto.
> 	(i386_darwin_push_dummy_call): Ditto.
> 	(i386_darwin_init_abi): Define Darwin specific push_dummy_call.
> 	Adjust long_double size.  Adjust pc offset in setjump buffer.
> 
> Index: i386-darwin-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/i386-darwin-tdep.c,v
> retrieving revision 1.6
> diff -c -p -r1.6 i386-darwin-tdep.c
> *** i386-darwin-tdep.c	3 Jul 2009 12:06:36 -0000	1.6
> --- i386-darwin-tdep.c	3 Jul 2009 15:48:55 -0000
> *************** darwin_dwarf_signal_frame_p (struct gdba
> *** 109,114 ****
> --- 109,241 ----
>    return i386_sigtramp_p (this_frame);
>  }
> 
> + /* Check wether TYPE is a 128-bit vector (__m128, __m128d or __m128i).  */
> + 
> + static inline int
> + i386_m128_p (struct type *type)
> + {
> +   return TYPE_CODE (type) == TYPE_CODE_ARRAY && TYPE_VECTOR (type)
> +     && TYPE_LENGTH (type) == 16;
> + }

Any reason why this function must be inline?  Ever since the bright
folks in the ISO committee decided to adpot different rules for things
like static inline and extern inline than GCC, the use of inline makes
me nervous.  And I believe modern compilers are very well capable
themselves of deciding if static functions should be inlined or not.


> + /* Check whether TYPE must be 16-byte-aligned when passed as a
> +    function argument.  16-byte vectors, _Decimal128 and structures or
> +    unions containing such types must be 16-byte-aligned; other
> +    arguments are 4-byte-aligned.  */

Hmm, this function actually returns the alignment (as a number of
bytes), but the comment suggests it's a predicate.  Can you adjust the
comment?

> + static int
> + i386_darwin_arg_type_alignment (struct type *type)
> + {
> +   type = check_typedef (type);
> +   /* Passing arguments.
> +      5.  The caller places 64-bit vectors (__m64) on the parameter area,
> +          aligned to 8-byte boundaries.

"on the parameter area"?  Probably a type.

> +      6.  [...]  The caller aligns 128-bit vectors in the parameter area to
> +          16-byte boundaries.  */
> +   if (TYPE_CODE (type) == TYPE_CODE_ARRAY && TYPE_VECTOR (type))
> +     return TYPE_LENGTH (type);
> +   /* 2.  The caller aligns nonvector arguments to 4-byte boundaries.  */
> +   return 4;
> + }
> + 
> + static CORE_ADDR
> + i386_darwin_push_dummy_call (struct gdbarch *gdbarch, struct value *function,
> + 			     struct regcache *regcache, CORE_ADDR bp_addr,
> + 			     int nargs, struct value **args, CORE_ADDR sp,
> + 			     int struct_return, CORE_ADDR struct_addr)
> + {
> +   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +   enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
> +   gdb_byte buf[4];
> +   int i;
> +   int write_pass;
> + 
> +   /* Determine the total space required for arguments and struct
> +      return address in a first pass (allowing for 16-byte-aligned
> +      arguments), then push arguments in a second pass.  */
> + 
> +   for (write_pass = 0; write_pass < 2; write_pass++)
> +     {
> +       int args_space = 0;
> +       int nbr_m128 = 0;

nbr_m128?  Is that supposed to mean number of m128's?  If so, would
you be so kind to reanem this variable num_m128?

> + 
> +       if (struct_return)
> + 	{
> + 	  if (write_pass)
> + 	    {
> + 	      /* Push value address.  */
> + 	      store_unsigned_integer (buf, 4, byte_order, struct_addr);
> + 	      write_memory (sp, buf, 4);
> + 	    }
> +           args_space += 4;
> + 	}
> + 
> +       for (i = 0; i < nargs; i++)
> + 	{
> +           struct type *arg_type = value_enclosing_type (args[i]);
> + 
> +           if (i386_m128_p (arg_type) && nbr_m128 < 4)
> +             {
> +               if (write_pass)
> +                 {
> +                   const gdb_byte *val = value_contents_all (args[i]);
> +                   regcache_raw_write
> +                     (regcache, I387_MM0_REGNUM(tdep) + nbr_m128, val);
> +                 }
> +               nbr_m128++;
> +             }
> +           else
> +             {
> +               int len = TYPE_LENGTH (arg_type);
> +               int align = i386_darwin_arg_type_alignment (arg_type);
> + 
> +               args_space = align_up (args_space, align);
> +               if (write_pass)
> +                 write_memory (sp + args_space,
> +                               value_contents_all (args[i]), len);
> + 
> +               /* The System V ABI says that:
> +                  
> +                  "An argument's size is increased, if necessary, to make it a
> +                  multiple of [32-bit] words.  This may require tail padding,
> +                  depending on the size of the argument."
> +                  
> +                  This makes sure the stack stays word-aligned.  */
> +               args_space += align_up (len, 4);
> +             }
> +         }
> + 
> +       /* Darwin i386 ABI:
> + 	 1.  The caller ensures that the stack is 16-byte aligned at the point
> + 	 of the function call.  */
> +       if (!write_pass)
> + 	sp = align_down (sp - args_space, 16);
> +     }
> + 
> +   /* Store return address.  */
> +   sp -= 4;
> +   store_unsigned_integer (buf, 4, byte_order, bp_addr);
> +   write_memory (sp, buf, 4);
> + 
> +   /* Finally, update the stack pointer...  */
> +   store_unsigned_integer (buf, 4, byte_order, sp);
> +   regcache_cooked_write (regcache, I386_ESP_REGNUM, buf);
> + 
> +   /* ...and fake a frame pointer.  */
> +   regcache_cooked_write (regcache, I386_EBP_REGNUM, buf);
> + 
> +   /* MarkK wrote: This "+ 8" is all over the place:
> +      (i386_frame_this_id, i386_sigtramp_frame_this_id,
> +      i386_dummy_id).  It's there, since all frame unwinders for
> +      a given target have to agree (within a certain margin) on the
> +      definition of the stack address of a frame.  Otherwise frame id
> +      comparison might not work correctly.  Since DWARF2/GCC uses the
> +      stack address *before* the function call as a frame's CFA.  On
> +      the i386, when %ebp is used as a frame pointer, the offset
> +      between the contents %ebp and the CFA as defined by GCC.  */
> +   return sp + 8;
> + }
> + 
>  static void
>  i386_darwin_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
>  {
> *************** i386_darwin_init_abi (struct gdbarch_inf
> *** 119,124 ****
> --- 246,252 ----
>    set_gdbarch_num_regs (gdbarch, I386_SSE_NUM_REGS);
> 
>    dwarf2_frame_set_signal_frame_p (gdbarch, darwin_dwarf_signal_frame_p);
> +   set_gdbarch_push_dummy_call (gdbarch, i386_darwin_push_dummy_call);
> 
>    tdep->struct_return = reg_struct_return;
> 
> *************** i386_darwin_init_abi (struct gdbarch_inf
> *** 127,133 ****
>    tdep->sc_reg_offset = i386_darwin_thread_state_reg_offset;
>    tdep->sc_num_regs = i386_darwin_thread_state_num_regs;
> 
> !   tdep->jb_pc_offset = 20;
> 
>    set_solib_ops (gdbarch, &darwin_so_ops);
>  }
> --- 255,266 ----
>    tdep->sc_reg_offset = i386_darwin_thread_state_reg_offset;
>    tdep->sc_num_regs = i386_darwin_thread_state_num_regs;
> 
> !   tdep->jb_pc_offset = 48;
> ! 
> !   /* Although the i387 extended floating-point has only 80 significant
> !      bits, a `long double' actually takes up 128, probably to enforce
> !      alignment.  */
> !   set_gdbarch_long_double_bit (gdbarch, 128);

This is true for the 32-bit Darwin ABI as well?

Re: [RFA Darwin]: Add push_dummy_call for i386

[Tristan Gingold]

On Jul 3, 2009, at 6:48 PM, Mark Kettenis wrote:

>> Date: Fri, 3 Jul 2009 17:51:52 +0200
>> From: Tristan Gingold <gingold@adacore.com>
>>
>> Hi,
>>
>> Darwin i386 ABI is slightly different from the SVR4 one.  In  
>> particular
>> stack alignment is 16.  As a consquence, i386 Darwin can't use the  
>> standard
>> i386-tdeo.c push_dummy_call and this patch provides a Darwin  
>> version of this
>> call.
>>
>> Regtested on i386 Darwin.
>> Tristan.
>
> Tristan, can you provide unified diffs instead of context diffs?   
> It's much easier to read the unified ones.

Sure, I can ;-)

>> + static inline int
>> + i386_m128_p (struct type *type)
>> + {
>> +   return TYPE_CODE (type) == TYPE_CODE_ARRAY && TYPE_VECTOR (type)
>> +     && TYPE_LENGTH (type) == 16;
>> + }
>
> Any reason why this function must be inline?  Ever since the bright
> folks in the ISO committee decided to adpot different rules for things
> like static inline and extern inline than GCC, the use of inline makes
> me nervous.  And I believe modern compilers are very well capable
> themselves of deciding if static functions should be inlined or not.

I will remove the inline.

>> + /* Check whether TYPE must be 16-byte-aligned when passed as a
>> +    function argument.  16-byte vectors, _Decimal128 and  
>> structures or
>> +    unions containing such types must be 16-byte-aligned; other
>> +    arguments are 4-byte-aligned.  */
>
> Hmm, this function actually returns the alignment (as a number of
> bytes), but the comment suggests it's a predicate.  Can you adjust the
> comment?

Sure.

>> + static int
>> + i386_darwin_arg_type_alignment (struct type *type)
>> + {
>> +   type = check_typedef (type);
>> +   /* Passing arguments.
>> +      5.  The caller places 64-bit vectors (__m64) on the  
>> parameter area,
>> +          aligned to 8-byte boundaries.
>
> "on the parameter area"?  Probably a type.

I quoted LowLevelABI.pdf.  What is wrong in this sentence ?  (Keep in  
mind that I am not a native
english speaker!)

>>
>> +   for (write_pass = 0; write_pass < 2; write_pass++)
>> +     {
>> +       int args_space = 0;
>> +       int nbr_m128 = 0;
>
> nbr_m128?  Is that supposed to mean number of m128's?  If so, would
> you be so kind to reanem this variable num_m128?

Ok.

>>
>> *************** i386_darwin_init_abi (struct gdbarch_inf
>> *** 127,133 ****
>>   tdep->sc_reg_offset = i386_darwin_thread_state_reg_offset;
>>   tdep->sc_num_regs = i386_darwin_thread_state_num_regs;
>>
>> !   tdep->jb_pc_offset = 20;
>>
>>   set_solib_ops (gdbarch, &darwin_so_ops);
>> }
>> --- 255,266 ----
>>   tdep->sc_reg_offset = i386_darwin_thread_state_reg_offset;
>>   tdep->sc_num_regs = i386_darwin_thread_state_num_regs;
>>
>> !   tdep->jb_pc_offset = 48;
>> !
>> !   /* Although the i387 extended floating-point has only 80  
>> significant
>> !      bits, a `long double' actually takes up 128, probably to  
>> enforce
>> !      alignment.  */
>> !   set_gdbarch_long_double_bit (gdbarch, 128);
>
> This is true for the 32-bit Darwin ABI as well?

This is true only for the i386 Darwin ABI.  Darwin strictly follows  
the SVR4 ABI for x86_64.

Tristan.

Re: [RFA Darwin]: Add push_dummy_call for i386

[Mark Kettenis]

> From: Tristan Gingold <gingold@adacore.com>
> Date: Mon, 6 Jul 2009 09:08:23 +0200
> 
> On Jul 3, 2009, at 6:48 PM, Mark Kettenis wrote:
> 
> >> + static int
> >> + i386_darwin_arg_type_alignment (struct type *type)
> >> + {
> >> +   type = check_typedef (type);
> >> +   /* Passing arguments.
> >> +      5.  The caller places 64-bit vectors (__m64) on the  
> >> parameter area,
> >> +          aligned to 8-byte boundaries.
> >
> > "on the parameter area"?  Probably a type.
> 
> I quoted LowLevelABI.pdf.  What is wrong in this sentence ?  (Keep
> in mind that I am not a native english speaker!)

Heh well, if it is a quotation, better not change it.  But perhaps the
comment should indicate this is a quotation from the ABI document?

Re: [RFA Darwin]: Add push_dummy_call for i386

[Tristan Gingold]

On Jul 6, 2009, at 12:16 PM, Mark Kettenis wrote:
>> I quoted LowLevelABI.pdf.  What is wrong in this sentence ?  (Keep
>> in mind that I am not a native english speaker!)
>
> Heh well, if it is a quotation, better not change it.  But perhaps the
> comment should indicate this is a quotation from the ABI document?

I propose this:

   /* According to Mac OS X ABI document (passing arguments):
      6.  The caller places 64-bit vectors (__m64) on the parameter  
area,
          aligned to 8-byte boundaries.
      7.  [...]  The caller aligns 128-bit vectors in the parameter  
area to
          16-byte boundaries.  */


Is it OK with that change (or do you prefer to review the whole patch  
again) ?

Tristan.

Re: [RFA Darwin]: Add push_dummy_call for i386

[Joseph S. Myers]

On Fri, 3 Jul 2009, Tristan Gingold wrote:

> Hi,
> 
> Darwin i386 ABI is slightly different from the SVR4 one.  In particular
> stack alignment is 16.  As a consquence, i386 Darwin can't use the standard
> i386-tdeo.c push_dummy_call and this patch provides a Darwin version of this
> call.

Are there tests in the testsuite (of GDB knowing how SSE vector arguments 
and function returns are handled) that this fixes?  (There are such tests 
for AltiVec and e500 vectors, for example.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [RFA Darwin]: Add push_dummy_call for i386

[Tristan Gingold]

On Jul 3, 2009, at 6:55 PM, Joseph S. Myers wrote:

> On Fri, 3 Jul 2009, Tristan Gingold wrote:
>
>> Hi,
>>
>> Darwin i386 ABI is slightly different from the SVR4 one.  In  
>> particular
>> stack alignment is 16.  As a consquence, i386 Darwin can't use the  
>> standard
>> i386-tdeo.c push_dummy_call and this patch provides a Darwin  
>> version of this
>> call.
>
> Are there tests in the testsuite (of GDB knowing how SSE vector  
> arguments
> and function returns are handled) that this fixes?  (There are such  
> tests
> for AltiVec and e500 vectors, for example.)

This example fixes many tests in callfuncs.exp.  If gdb calls malloc()  
(eg to allocate a string) with
a wrong stack alignment, the inferior will crash (as it looks like  
malloc or one of its callees uses sse).

That's said, I haven't seen tests for SSE vector arguments/return.

Tristan.

Re: [RFA Darwin]: Add push_dummy_call for i386

[H.J. Lu]

On Fri, Jul 3, 2009 at 8:51 AM, Tristan Gingold<gingold@adacore.com> wrote:
> Hi,
>
> Darwin i386 ABI is slightly different from the SVR4 one.  In particular
> stack alignment is 16.  As a consquence, i386 Darwin can't use the standard
> i386-tdeo.c push_dummy_call and this patch provides a Darwin version of this
> call.
>

Well, the code generated by gcc for Linux/i386 assumes that the incoming
stack is aligned at 16byte. If not, functions using SSE registers may crash.


-- 
H.J.

Re: [RFA Darwin]: Add push_dummy_call for i386

[Tristan Gingold]

On Jul 4, 2009, at 5:31 PM, H.J. Lu wrote:

> On Fri, Jul 3, 2009 at 8:51 AM, Tristan Gingold<gingold@adacore.com>  
> wrote:
>> Hi,
>>
>> Darwin i386 ABI is slightly different from the SVR4 one.  In  
>> particular
>> stack alignment is 16.  As a consquence, i386 Darwin can't use the  
>> standard
>> i386-tdeo.c push_dummy_call and this patch provides a Darwin  
>> version of this
>> call.
>>
>
> Well, the code generated by gcc for Linux/i386 assumes that the  
> incoming
> stack is aligned at 16byte. If not, functions using SSE registers  
> may crash.

Interesting, as I can't see the code that preserve stack alignment in  
i386-tdep.c
Anyway, i386/Darwin needs to have its own push_dummy_call code as it  
doesn't follow
that SVR4 ABI on many points.

Tristan.