Re: compatibility between gdb and stub

[Romain Berrendonner <berrendo at ACT-Europe dot FR>]

On 2002-11-18, Kevin Buettner wrote :

> On Nov 18,  3:09pm, Romain Berrendonner wrote:
> 
> > The file rs6000-tdep.c however, which was very similar in gdb 5.1 and
> > gdb 5.2, changed in the 5.3 branch, causing interoperability disruption
> > with older stubs, due to the definition of fpscr.
> 
> It was my intent to add fpscr in such a way so that existing stubs
> would not be broken.  It sounds like I didn't succeed.  Can you explain
> the problem that you're seeing?

Here's my understanding of how the 'G' and 'g' commands work: 

1/ gdb has a list of all registers for the variant of processor it is
currently using. Each register has a size (4 or 8 bytes).

2/ When it need to send a 'G' packet, it concatenates the contents of
all the registers, as specified in the definition: the number of
registers, their size and their order matters. Conversely, when it needs
to parse a 'g' packet, it knows the value of each registers by the value
of the bytes corresponding to its position in the data flow.

Now, I have a stub working with 5.1, and I'm considering using it with 5.3.
In rs6000-tdep.c for gdb 5.1 we got:

#define PPC_UISA_SPRS \
  /* 66 */ R4(cr),  R(lr), R(ctr), R4(xer), R0

In rs6000-tdep.c for gdb 5.3 we got:

#define PPC_UISA_SPRS \
  /* 66 */ R4(cr),  R(lr), R(ctr), R4(xer), R4(fpscr)

So the slot 70 is now used, while it was empty before. This is why I suspected
a non-compatibility with older stubs.

Don't hesitate to correct me if I'm wrong :-)

-- 
Romain