[obish] Delete PARM_BOUNDARY
Michael Snyder
msnyder@redhat.com
Tue May 4 20:08:00 GMT 2004
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)
More information about the Gdb-patches
mailing list