Re: i386_register_raw_size[]

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   Date: Wed, 23 Feb 2000 14:28:19 -0500 (EST)
   From: Eli Zaretskii <eliz@delorie.com>


   i386-tdep.c defines the array used to compute REGISTER_RAW_SIZE
   thusly:

       /* i386_register_raw_size[i] is the number of bytes of storage in the
	  actual machine representation for register i.  */
       int i386_register_raw_size[MAX_NUM_REGS] = {
	  4,  4,  4,  4,
	  4,  4,  4,  4,
	  4,  4,  4,  4,
	  4,  4,  4,  4,
	 10, 10, 10, 10,
	 10, 10, 10, 10,
	  4,  4,  4,  4,    <<<<<
	  4,  4,  4,  4,    <<<<<
	 16, 16, 16, 16,
	 16, 16, 16, 16,
	  4
       };

   The registers marked with "<<<<<" are the ones I want to discuss.
   These are control, status, and tag words, and the FP instruction
   address and operands.  The ``raw'' part of the name and the comment
   imply that these should have the same size as they are saved by the
   low-level debug support functions on the target machine.  I interpret
   that as the layout in memory of the data saved by FSAVE and similar
   instructions.

I think ``raw'' implies that the data isn't yet interpreted by GDB
yet, i.e. it is in the target byte order.

   However, the above definition of i386_register_raw_size[] does not
   follow the FPU state layout as saved by FSAVE.  For example, the
   actual length of the control/status/tag words is 2 bytes, not 4, and
   the last register, the opcode occupies the 2 upper bytes of the same
   4-byte word as the FP instruction selector.

Messy ain't it?  That, the fact that there exist other i386
instructions that use a different layout to store the same data, and
the possibility of other OS'es that present the data ina very
different layout, were the reasons to simply pretend that these are
32-bit registers.  This was discussed in detail last fail.  I believe
the start of the thread is:

http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00033.html

   I don't have any problems to create an illusion in go32-nat.c that the
   FP register layout is like implied by i386_register_raw_size[],
   especially if it turns out that DJGPP is the only x86 target which
   doesn't already comply with this layout.  But is this really the
   intent--to have all x86 targets use the same raw layout of registers,
   and if so, why do we need the corresponding virtual_size array and
   macros?

Yes, that's what you are supposed to do!  Look at i386gnu-nat.c and
i386-linux-nat.c to see examples.  It is really the intent to have the
same layout on all x86 targets, since this makes it easier to use the
same GDB for different x86 targets.  The virtual_size array and the
macro's are still necessary, since the raw data still needs to be
interpreted to take into account differences in endianness or floating
point types if GDB runs on a host with a different architecture than
the target.

Mark