compatibility between gdb and stub

compatibility between gdb and stub

[Romain Berrendonner]

Hi folks,

I would like to know what is the policy regarding the compatibility
between gdb and the target stubs: as far as I understand, the way `g'
and 'G' commands work requires that the debugger and the stub have the
very same definition of the target's registers.

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.

Is this correct ? Is there a policy for handling that kind of issues ?
-- 
Romain

Re: compatibility between gdb and stub

[Andrew Cagney]

> Hi folks,
> 
> I would like to know what is the policy regarding the compatibility
> between gdb and the target stubs: as far as I understand, the way `g'
> and 'G' commands work requires that the debugger and the stub have the
> very same definition of the target's registers.
> 
> 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.
> 
> Is this correct ? Is there a policy for handling that kind of issues ?

Almost.  GDB can change it's architecture, and hence, supported register 
set.  See the command `set architecture'.

As for the underlying problem.  remote.c is probably 50% through an 
overhaul that removes the restrictions such as you describe (its been in 
that state for a few months.  Interested?).

enjoy,
Andrew

Re: compatibility between gdb and stub

[Romain Berrendonner]

On 2002-11-18, Andrew Cagney wrote :

> Almost.  GDB can change it's architecture, and hence, supported register 
> set.  See the command `set architecture'.

Well, my understanding is that it is usefull if you want to define several
variants in a family of processors, but if a given variant's definition 
changes, how can the stub deal with this ?

> As for the underlying problem.  remote.c is probably 50% through an 
> overhaul that removes the restrictions such as you describe (its been in 
> that state for a few months.  Interested?).

I'm glad to hear that. I guess that it will significantly change the
definition of the remote protocol ?

-- 
Romain

Re: compatibility between gdb and stub

[Kevin Buettner]

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?

Kevin

Re: compatibility between gdb and stub

[Steven Johnson]

I had this problem as well, for the MPC860 target.

The fpscr didn't used to be required, but now it is.  The result was 
that all registers below it were shifted up by one.  I actually noticed 
it because the PVR was telling me zero, which is an invalid processor 
version. I fixed it by changing my stub, but it was annoying.

The other thing that is annoying is the generic powerpc target wont work 
with a MPC860 stub and vice versa.  What would be nice is a query 
mechanism where at connection, GDB can say "I want these registers" and 
the stub can return "Thats fine, but of the registers you want, these 
are the ones i support."  Then in a block registers response or write 
from/to the target, the registers would be sent and received in the 
order they appeared. This could also set the value of the index for N 
for the p/P packets.

something like (for a pretend processor):

qRegisters:pc,32;sp,32;flags,16;fpflags,16;r0,32;r1,32;r2,32;r3,32;r4,32;
r5,32;r6,32;r7,32;r8,32;f0,64;f1,64;f2,64;f3,64;f4,64;f5,64;f6,64;f7,64;f8,64;

which for a stub that runs on a varient of the processor without 
floating point would respond:

qRegisters:pc,32;sp,32;flags,16;r0,32;r1,32;r2,32;r3,32;r4,32;
r5,32;r6,32;r7,32;r8,32;

if the stub supported more registers than GDB asked for, then the stub 
would just not return them. If the stub was an old stub and didn't 
support this, then GDB would not get the qRegisters response, and so 
would not reduce it's expectations of what registers it could use in a 
stub. And so would work as it does now.

Then the index for p/p would be:
pc = 0
sp = 1
r4 = 7
and so on.

There would be performance advantages to this scheme as well, because 
currently stubs are required to return registers that their target does 
not support. For example, the powerpc:MPC860 target does not support 
floating point, but the stub is still required to return them, and there 
are 32 of them and they are 64 bits wide!!

This would also allow the not so great statement in the description of 
the 'g' packet: "The size of each register and their position within the 
'g' PACKET are determined by the GDB internal macros' to be replaced 
with something more concrete like: see qRegisters for details of the 
order and size of registers, stubs that do not support qRegisters must 
refer to GDB internal macros.

What do people think?

Steven Johnson

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?
> 
> Kevin
> 

Re: compatibility between gdb and stub

[Daniel Jacobowitz]

On Tue, Nov 19, 2002 at 11:34:40AM +1000, Steven Johnson wrote:
> I had this problem as well, for the MPC860 target.
> 
> The fpscr didn't used to be required, but now it is.  The result was 
> that all registers below it were shifted up by one.  I actually noticed 
> it because the PVR was telling me zero, which is an invalid processor 
> version. I fixed it by changing my stub, but it was annoying.
> 
> The other thing that is annoying is the generic powerpc target wont work 
> with a MPC860 stub and vice versa.  What would be nice is a query 
> mechanism where at connection, GDB can say "I want these registers" and 
> the stub can return "Thats fine, but of the registers you want, these 
> are the ones i support."  Then in a block registers response or write 
> from/to the target, the registers would be sent and received in the 
> order they appeared. This could also set the value of the index for N 
> for the p/P packets.
> 
> something like (for a pretend processor):
> 
> qRegisters:pc,32;sp,32;flags,16;fpflags,16;r0,32;r1,32;r2,32;r3,32;r4,32;
> r5,32;r6,32;r7,32;r8,32;f0,64;f1,64;f2,64;f3,64;f4,64;f5,64;f6,64;f7,64;f8,64;
> 
> which for a stub that runs on a varient of the processor without 
> floating point would respond:
> 
> qRegisters:pc,32;sp,32;flags,16;r0,32;r1,32;r2,32;r3,32;r4,32;
> r5,32;r6,32;r7,32;r8,32;
> 
> if the stub supported more registers than GDB asked for, then the stub 
> would just not return them. If the stub was an old stub and didn't 
> support this, then GDB would not get the qRegisters response, and so 
> would not reduce it's expectations of what registers it could use in a 
> stub. And so would work as it does now.
> 
> Then the index for p/p would be:
> pc = 0
> sp = 1
> r4 = 7
> and so on.
> 
> There would be performance advantages to this scheme as well, because 
> currently stubs are required to return registers that their target does 
> not support. For example, the powerpc:MPC860 target does not support 
> floating point, but the stub is still required to return them, and there 
> are 32 of them and they are 64 bits wide!!
> 
> This would also allow the not so great statement in the description of 
> the 'g' packet: "The size of each register and their position within the 
> 'g' PACKET are determined by the GDB internal macros' to be replaced 
> with something more concrete like: see qRegisters for details of the 
> order and size of registers, stubs that do not support qRegisters must 
> refer to GDB internal macros.
> 
> What do people think?

Everyone agrees.  I've even posted an implementation of qRegisters
that's a simplified version of the above.  But that patch is out of
date now and Andrew wanted something more flexible at the time, IIRC...

I suspect we're getting closer and someone just needs to do the work
again.

> 
> Steven Johnson
> 
> 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?
> >
> >Kevin
> >
> 
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: compatibility between gdb and stub

[Romain Berrendonner]

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

Re: compatibility between gdb and stub

[Kevin Buettner]

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

Re: compatibility between gdb and stub

[Andrew Cagney]

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

Yes.

Andrew

Re: compatibility between gdb and stub

[Romain Berrendonner]

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.

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.

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

-- 
Romain

Re: compatibility between gdb and stub

[Andrew Cagney]

> 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

Re: compatibility between gdb and stub

[Steven Johnson]

The real problem here is that the Common Registers of PowerPC are not 
uniform across the chips. I think the only ones that can truly be said 
to be common are R0-R31,pc,msr,lr,ctr,flags  The macros defined, assume 
a whole lot about what is common, that isn't.

And having written an "old stub" for the MPC860, I can confidently say 
that old stubs did not supply zeros where fpscr is, they didn't send 
anything as GDB did not expect anything.

Obviously there would need to be some understanding in the stub of what 
registers GDB used, but I fail to see that GDB is ever going to 
permenantly define a packet layout and stick to it.

Steven

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

Re: compatibility between gdb and stub

[Andrew Cagney]

> The real problem here is that the Common Registers of PowerPC are not uniform across the chips. I think the only ones that can truly be said to be common are R0-R31,pc,msr,lr,ctr,flags  The macros defined, assume a whole lot about what is common, that isn't.
> 
> And having written an "old stub" for the MPC860, I can confidently say that old stubs did not supply zeros where fpscr is, they didn't send anything as GDB did not expect anything.

That is fine.

New registers get added to the end.  Consequently, an old target (which 
knows zip about those registers) would send what GDB views as a short 
packet.  GDB would mark the missing registers (which should have been at 
the end of the packet) as being zero.

> Obviously there would need to be some understanding in the stub of what registers GDB used, but I fail to see that GDB is ever going to permenantly define a packet layout and stick to it.

Part of the definition is that the packet can grow and grow and grow. 
You just can't go back and re-format it.

The outstanding change, though, is for GDB to allow sparse register 
numbers in the remote protocol.  The P4, for instance, has two thousand 
million potential MSR registers.  Such registers would need to be 
fetched using something other than the [gG] packet (i.e., the [Pp] packets).

Andrew

Re: compatibility between gdb and stub

[Kevin Buettner]

On Nov 21, 10:44am, Romain Berrendonner wrote:

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

This would be true if fpscr was simply added in the middle.  However,
when I "added" fpscr, I made it replace a previously unused slot.  So,
what should happen in this case is that gdb will simply get a zero (or
some other bogus value) for fpscr.

Kevin