Re: compatibility between gdb and stub

[Kevin Buettner <kevinb at redhat dot com>]

On Nov 19, 10:20am, Romain Berrendonner wrote:

> 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.

As I understand it, if a stub replies with a short "g" packet, then
gdb will simply regard the missing registers as being unavailable.

Kevin