Re: compatibility between gdb and stub

Steven Johnson
2002-11-19T01:40:40Z

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
>