Re: [obish] Delete PARM_BOUNDARY

[Michael Snyder <msnyder@redhat.com>]

Andrew Cagney wrote:
> Hello,
> 
> Other posts drew my attention to this:
> 
> - PARM_BOUNDARY is only used by push_value
> 
> - push_value is only used by legacy_push_arguments.
> 
> - legacy_push_arguments is only used when push_dummy_call isn't supplied
> 
> yet:
> 
> - only m68k sets PARAM_BOUNDARY
> 
> - m68k sets (as of recent changes) push_dummy_call
> 
> hence PARM_BOUNDARY is dead.
> 
> baring comments I'll commit this in a day or so,
> 
> Andrew

Thanks -- I was going to suggest it.

> ------------------------------------------------------------------------
> 
> 	* gdbarch.sh (PARM_BOUNDARY): Delete.
> 	gdbarch.h, gdbarch.c: Re-generate.
> 	* valops.c (PARM_BOUNDARY): Delete macro.
> 	(value_push): Delete PARM_BOUNDARY code.
> 	* m68k-tdep.c (m68k_gdbarch_init): Do not set parm_boundary.
> 
> Index: gdbarch.sh
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbarch.sh,v
> retrieving revision 1.310
> diff -p -u -r1.310 gdbarch.sh
> --- gdbarch.sh	1 May 2004 16:52:29 -0000	1.310
> +++ gdbarch.sh	4 May 2004 18:28:51 -0000
> @@ -673,7 +673,6 @@ M:::CORE_ADDR:frame_align:CORE_ADDR addr
>  F:2:DEPRECATED_REG_STRUCT_HAS_ADDR:int:deprecated_reg_struct_has_addr:int gcc_p, struct type *type:gcc_p, type
>  m:::int:stabs_argument_has_addr:struct type *type:type:::default_stabs_argument_has_addr::0
>  v::FRAME_RED_ZONE_SIZE:int:frame_red_zone_size
> -v:2:PARM_BOUNDARY:int:parm_boundary
>  #
>  v:2:TARGET_FLOAT_FORMAT:const struct floatformat *:float_format::::::default_float_format (current_gdbarch)::%s:(TARGET_FLOAT_FORMAT)->name
>  v:2:TARGET_DOUBLE_FORMAT:const struct floatformat *:double_format::::::default_double_format (current_gdbarch)::%s:(TARGET_DOUBLE_FORMAT)->name
> Index: m68k-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/m68k-tdep.c,v
> retrieving revision 1.85
> diff -p -u -r1.85 m68k-tdep.c
> --- m68k-tdep.c	3 May 2004 21:56:09 -0000	1.85
> +++ m68k-tdep.c	4 May 2004 18:28:51 -0000
> @@ -1107,7 +1107,6 @@ m68k_gdbarch_init (struct gdbarch_info i
>  
>    /* Stack grows down. */
>    set_gdbarch_inner_than (gdbarch, core_addr_lessthan);
> -  set_gdbarch_parm_boundary (gdbarch, 32);
>  
>    set_gdbarch_believe_pcc_promotion (gdbarch, 1);
>    set_gdbarch_decr_pc_after_break (gdbarch, 2);
> Index: valops.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/valops.c,v
> retrieving revision 1.125
> diff -p -u -r1.125 valops.c
> --- valops.c	30 Apr 2004 14:12:46 -0000	1.125
> +++ valops.c	4 May 2004 18:28:54 -0000
> @@ -1005,10 +1005,6 @@ push_bytes (CORE_ADDR sp, char *buffer, 
>    return sp;
>  }
>  
> -#ifndef PARM_BOUNDARY
> -#define PARM_BOUNDARY (0)
> -#endif
> -
>  /* Push onto the stack the specified value VALUE.  Pad it correctly for
>     it to be an argument to a function.  */
>  
> @@ -1018,11 +1014,6 @@ value_push (CORE_ADDR sp, struct value *
>    int len = TYPE_LENGTH (VALUE_ENCLOSING_TYPE (arg));
>    int container_len = len;
>    int offset;
> -
> -  /* How big is the container we're going to put this value in?  */
> -  if (PARM_BOUNDARY)
> -    container_len = ((len + PARM_BOUNDARY / TARGET_CHAR_BIT - 1)
> -		     & ~(PARM_BOUNDARY / TARGET_CHAR_BIT - 1));
>  
>    /* Are we going to put it at the high or low end of the container?  */
>    if (TARGET_BYTE_ORDER == BFD_ENDIAN_BIG)