Re: compatibility between gdb and stub

[Daniel Jacobowitz <drow at mvista dot com>]

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