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]

Re: Unifying the x86 FPU register sets



> It's unfortunate that we cannot do this, as it requires the debug
> agent to have extra code to pack/unpack the floating point registers.
> This may not be an issue in a OS kernel, but it could be in embedded
> devices.  This was less of an issue pre-MMX, since FP operations are
> not typically used in embedded systems, but integer vector operations
> are more likely to be.

I think it really just means two copy loops instead of one; the stack
and control regions are just swapped.  Could you give this a try and
see how it goes?

I don't have strong opinions about the register names.  I've renamed
the FPU instruction and operand pointers almost as you suggest:

  FPU instruction pointer:  $fis, $fioff
  FPU operand pointer:      $fos, $fooff

Would $fiseg and $foseg be clearer?

> It took me a double, and even triple, take to figure out what $fcs,
> $fcoff, $fds, and $fdoff meant.  Since these registers are called the
> FPU instruction pointer and FPU operand pointer, why not $fis, $fioff,
> $fos, and $fooff?  I don't think anything has been gained by renaming
> them.

I mostly wanted to improve on the existing practice of stuffing the
opcode and the instruction pointer segment into the same GDB register,
which is lame.  As far as I know, all extant GDB targets which offer
any access to the FPU control registers at all do this.

> Jim> /* This register file is parameterized by two macros:
> Jim>    HAVE_I387_REGS --- register file should include i387 registers
> Jim>    HAVE_SSE_REGS --- register file should include SSE registers
> Jim>    If HAVE_SSE_REGS is #defined, then HAVE_I387_REGS must also be
> Jim>    #defined.
> 
> Don't you think we need to make this run-time selectable based on
> processor type?  For example, we have I/O cards with 386ex's with 
> no FPU at all and forwarding engine that uses a pentium MMX.  I'd
> like to support both with a single GDB.

Yes.  It's my understanding that we can accomplish this with the
gdbarch mechanism.

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