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
>