This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
i386_register_raw_size[]
- To: gdb at sourceware dot cygnus dot com
- Subject: i386_register_raw_size[]
- From: Eli Zaretskii <eliz at delorie dot com>
- Date: Wed, 23 Feb 2000 14:28:19 -0500 (EST)
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.
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.
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?