Re: compatibility between gdb and stub

[Andrew Cagney <ac131313@redhat.com>]

> On 2002-11-20, Kevin Buettner wrote :
> 
> 
>> 
>> As I understand it, if a stub replies with a short "g" packet, then
>> gdb will simply regard the missing registers as being unavailable.
>> 
> 
> Let's take the example of the 750, with a stub not aware of fpscr.

/* Motorola/IBM PowerPC 750 or 740.  */
static const struct reg registers_750[] =
{
   COMMON_UISA_REGS,
   PPC_UISA_SPRS,
   PPC_SEGMENT_REGS,
   PPC_OEA_SPRS,
   /* 119 */ R(hid0), R(hid1), R(iabr), R(dabr),
   /* 123 */ R0, R(ummcr0), R(upmc1), R(upmc2),
   /* 127 */ R(usia), R(ummcr1), R(upmc3), R(upmc4),
   /* 131 */ R(mmcr0), R(pmc1), R(pmc2), R(sia),
   /* 135 */ R(mmcr1), R(pmc3), R(pmc4), R(l2cr),
   /* 139 */ R(ictc), R(thrm1), R(thrm2), R(thrm3)
};

/* UISA-level SPRs for PowerPC.  */
#define PPC_UISA_SPRS \
   /* 66 */ R4(cr),  R(lr), R(ctr), R4(xer), R4(fpscr)

So `fpscr' is 70 and it goes with the comment:

    Note: kevinb/2002-04-30: Support for the fpscr register was added
    during April, 2002.  Slot 70 is being used for PowerPC and slot 71
    for Power.  For PowerPC, slot 70 was unused and was already in the
    PPC_UISA_SPRS which is ideally where fpscr should go.  For Power,
    slot 70 was being used for "mq", so the next available slot (71)
    was chosen.  It would have been nice to be able to make the
    register numbers the same across processor cores, but this wasn't
    possible without either 1) renumbering some registers for some
    processors or 2) assigning fpscr to a really high slot that's
    larger than any current register number.  Doing (1) is bad because
    existing stubs would break.  Doing (2) is undesirable because it
    would introduce a really large gap between fpscr and the rest of
    the registers for most processors.  */

 > They are many registers after fpscr (the first of them is sr0).
 > With this scheme, when the stub sends back the answer to a 'g' packet,
 > gdb will consider that the content of fpscr is the content of sr0, 
and that
 > thrm3 (the last register) is not available.

No.  An old stub would supply zeros instead of "fpscr".

> This is clumsy, but the 'qRegisters' packet should improve this behaviour :-)

qRegisters isn't a `silver bullet' :-/  The bottom line is that GDB and 
the stub need to agree to a packet layout and then stick to it.

Andrew