This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

i386_register_raw_size[]



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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]