Re: [RFA] gdbarch.sh: document REGISTER_SIZE and REGISTER_BYTES

[Andrew Cagney <ac131313 at cygnus dot com>]

Nicholas Duffek wrote:
> 
> This patch adds comments documenting REGISTER_SIZE and REGISTER_BYTES in
> gdbarch.sh.
> 
> ChangeLog:
> 
>         * gdbarch.sh (REGISTER_SIZE, REGISTER_BYTES): Document.
>         * gdbarch.h: Regenerate.
> 
> Okay to apply?
> 
> Nicholas Duffek
> <nsd@redhat.com>
> 
> [patch follows]
> 
> Index: gdb/gdbarch.sh
> ===================================================================
> diff -up gdb/gdbarch.sh gdb/gdbarch.sh
> --- gdb/gdbarch.sh      Tue Jan  2 16:03:15 2001
> +++ gdb/gdbarch.sh      Tue Jan  2 16:02:42 2001
> @@ -383,7 +383,10 @@ f:2:DWARF_REG_TO_REGNUM:int:dwarf_reg_to
>  f:2:SDB_REG_TO_REGNUM:int:sdb_reg_to_regnum:int sdb_regnr:sdb_regnr:::no_op_reg_to_regnum::0
>  f:2:DWARF2_REG_TO_REGNUM:int:dwarf2_reg_to_regnum:int dwarf2_regnr:dwarf2_regnr:::no_op_reg_to_regnum::0
>  f:2:REGISTER_NAME:char *:register_name:int regnr:regnr:::legacy_register_name::0

> +# Size of an instruction.

At a guess you've been looking at that that really bizare code in
valops.c and breakpoint.c where GDB uses register_size and byte swapping
to create the call sequence for a dummy frame.

  /* CALL_DUMMY is an array of words (REGISTER_SIZE), but each word
     is in host byte order.  Before calling FIX_CALL_DUMMY, we byteswap
it
     and remove any extra bytes which might exist because ULONGEST is
     bigger than REGISTER_SIZE.

     NOTE: This is pretty wierd, as the call dummy is actually a
     sequence of instructions.  But CISC machines will have
     to pack the instructions into REGISTER_SIZE units (and
     so will RISC machines for which INSTRUCTION_SIZE is not
     REGISTER_SIZE).

     NOTE: This is pretty stupid.  CALL_DUMMY should be in strict
     target byte order. */

REGISTER_SIZE isn't an instruction size - take a look at the VAX.  It is
the size of an arbitrarially selected register.  As GDBINT.texinfo
mentions:

	@item CALL_DUMMY_WORDS
	....
	Should be deprecated in favour of a macro that uses target-byte-ordered
	data.

>  v:2:REGISTER_SIZE:int:register_size::::0:-1

> +# Total number of bytes needed to store raw registers, including
> +# pseudo-registers.

Given that pseudo-register values are created using a fuction and raw
register data, do they have any storage?

>  v:2:REGISTER_BYTES:int:register_bytes::::0:-1
>  f:2:REGISTER_BYTE:int:register_byte:int reg_nr:reg_nr::0:0
>  f:2:REGISTER_RAW_SIZE:int:register_raw_size:int reg_nr:reg_nr::0:0

	Andrew