Re: compatibility between gdb and stub

Daniel Jacobowitz
2002-11-19T01:43:49Z

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