This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: i386_register_raw_size[]
- To: eliz at delorie dot com
- Subject: Re: i386_register_raw_size[]
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Wed, 23 Feb 2000 22:00:49 +0100
- CC: gdb at sourceware dot cygnus dot com
- References: <200002231928.OAA18661@indy.delorie.com>
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