Discussion:
[help] Issues with 'g' packet and MIPS - gdb interprets the packet reply wrong
(too old to reply)
Christopher Bainbridge
2014-10-21 11:15:33 UTC
Permalink
Hi all,

I am trying to implement a remote stub for a MIPS cpu (using GDB version
7.8). When GDB asks for the general registers using the 'g' packet, I
reply with:

00000000000000000d01000000000000fffdffff00000000000000000080c0bf30000000f0fec0bf000000002e0000000000000000000000000000008080808000000000000000000000000000000000000000000000000000000000000000000000000000000000000001800000000000000000e8fec0bf00000000702ec0bf0000000000000000000000000000000000000000702ec0bf

As each register is 32 bits (represented by 8 hex characters), this
should be all the registers up to and including the PC.

However, GDB prints this out:

info reg
zero at v0 v1 a0 a1 a2 a3
R0 00000000 0000010d fffffdff 00000000 00000030 00000000 00000000
00000000
t0 t1 t2 t3 t4 t5 t6 t7
R8 00000000 00000000 00000000 00000000 00000000 80010000 00000000
00000000
s0 s1 s2 s3 s4 s5 s6 s7
Sending packet: $p13#d4...Ack
Packet received: 00000000
Sending packet: $p14#d5...Ack
Packet received: 00000000
Sending packet: $p15#d6...Ack
Packet received: 00000000
Sending packet: $p16#d7...Ack
Packet received: 00000000
Sending packet: $p17#d8...Ack
Packet received: 00000000
R16 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
t8 t9 k0 k1 gp sp s8 ra
Sending packet: $p18#d9...Ack
Packet received: 00000000
Sending packet: $p19#da...Ack
Packet received: 00000000
Sending packet: $p1a#02...Ack
Packet received: 00000180
Sending packet: $p1b#03...Ack

etc

This looks to be that it is determining the size of each register
incorrectly, and is thus asking for more registers using the 'p' packet.

Is this a bug on my end or in GDB?
I use the command

set processor mips:14000

beforehand, as this is the processor we're using.

Thanks,
Chris
Maciej W. Rozycki
2014-10-21 20:34:47 UTC
Permalink
Hi Christopher,
I am trying to implement a remote stub for a MIPS cpu (using GDB version 7.8).
00000000000000000d01000000000000fffdffff00000000000000000080c0bf30000000f0fec0bf000000002e0000000000000000000000000000008080808000000000000000000000000000000000000000000000000000000000000000000000000000000000000001800000000000000000e8fec0bf00000000702ec0bf0000000000000000000000000000000000000000702ec0bf
As each register is 32 bits (represented by 8 hex characters), this should be
all the registers up to and including the PC.
What makes you assume the registers are 32 bits each?
info reg
zero at v0 v1 a0 a1 a2 a3
R0 00000000 0000010d fffffdff 00000000 00000030 00000000 00000000 00000000
t0 t1 t2 t3 t4 t5 t6 t7
R8 00000000 00000000 00000000 00000000 00000000 80010000 00000000 00000000
s0 s1 s2 s3 s4 s5 s6 s7
Sending packet: $p13#d4...Ack
Packet received: 00000000
Sending packet: $p14#d5...Ack
Packet received: 00000000
Sending packet: $p15#d6...Ack
Packet received: 00000000
Sending packet: $p16#d7...Ack
Packet received: 00000000
Sending packet: $p17#d8...Ack
Packet received: 00000000
R16 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
t8 t9 k0 k1 gp sp s8 ra
Sending packet: $p18#d9...Ack
Packet received: 00000000
Sending packet: $p19#da...Ack
Packet received: 00000000
Sending packet: $p1a#02...Ack
Packet received: 00000180
Sending packet: $p1b#03...Ack
etc
This looks to be that it is determining the size of each register incorrectly,
and is thus asking for more registers using the 'p' packet.
Is this a bug on my end or in GDB?
I use the command
set processor mips:14000
beforehand, as this is the processor we're using.
You mean:

(gdb) set architecture mips:14000

I presume, right?

The R14000 is a 64-bit processor so its registers are 64-bit and will be
treated as such by default by GDB. You may be able to limit the width of
registers expected by selecting a 32-bit processor instead or by selecting
a 32-bit ABI such as `o32'. The latter can be done with:

(gdb) set mips abi o32

or by selecting a file to debug that has been built for that ABI.

Please note that this is a grey area though, with a bare-metal stub you
should be really exchanging registers with GDB in their native sizes and
letting GDB truncate and extend them as required depending on the ABI used
by the program being debugged. GDB is already capable of doing that,
however in order to make use of that capability both the stub and GDB
would have to support XML register descriptions which is something that
owing to the vast number of CP0 register set variants in the MIPS
architecture has never been implemented. So in fact you may be hitting
problems regardless of the ABI selection noted above.

You can always determine the widths of registers GDB expects with the:

(gdb) maintenance print registers

command -- see the `Type' column on the right for the internal type used
and note that the registers exchanged with a remote stub are those in the
low half of indices (`Nr' == `Rel'), the so called "raw registers".

HTH,

Maciej
Christopher Bainbridge
2014-10-22 10:31:46 UTC
Permalink
Many thanks!

It turns out that I mistook the M14000 to be the same as the M14k...
which, annoyingly, they aren't.

So doing:

set architecture mips:isa32r2

has solved my problem.

Thanks a lot!
Chris
Post by Maciej W. Rozycki
Hi Christopher,
I am trying to implement a remote stub for a MIPS cpu (using GDB version 7.8).
00000000000000000d01000000000000fffdffff00000000000000000080c0bf30000000f0fec0bf000000002e0000000000000000000000000000008080808000000000000000000000000000000000000000000000000000000000000000000000000000000000000001800000000000000000e8fec0bf00000000702ec0bf0000000000000000000000000000000000000000702ec0bf
As each register is 32 bits (represented by 8 hex characters), this should be
all the registers up to and including the PC.
What makes you assume the registers are 32 bits each?
info reg
zero at v0 v1 a0 a1 a2 a3
R0 00000000 0000010d fffffdff 00000000 00000030 00000000 00000000 00000000
t0 t1 t2 t3 t4 t5 t6 t7
R8 00000000 00000000 00000000 00000000 00000000 80010000 00000000 00000000
s0 s1 s2 s3 s4 s5 s6 s7
Sending packet: $p13#d4...Ack
Packet received: 00000000
Sending packet: $p14#d5...Ack
Packet received: 00000000
Sending packet: $p15#d6...Ack
Packet received: 00000000
Sending packet: $p16#d7...Ack
Packet received: 00000000
Sending packet: $p17#d8...Ack
Packet received: 00000000
R16 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
t8 t9 k0 k1 gp sp s8 ra
Sending packet: $p18#d9...Ack
Packet received: 00000000
Sending packet: $p19#da...Ack
Packet received: 00000000
Sending packet: $p1a#02...Ack
Packet received: 00000180
Sending packet: $p1b#03...Ack
etc
This looks to be that it is determining the size of each register incorrectly,
and is thus asking for more registers using the 'p' packet.
Is this a bug on my end or in GDB?
I use the command
set processor mips:14000
beforehand, as this is the processor we're using.
(gdb) set architecture mips:14000
I presume, right?
The R14000 is a 64-bit processor so its registers are 64-bit and will be
treated as such by default by GDB. You may be able to limit the width of
registers expected by selecting a 32-bit processor instead or by selecting
(gdb) set mips abi o32
or by selecting a file to debug that has been built for that ABI.
Please note that this is a grey area though, with a bare-metal stub you
should be really exchanging registers with GDB in their native sizes and
letting GDB truncate and extend them as required depending on the ABI used
by the program being debugged. GDB is already capable of doing that,
however in order to make use of that capability both the stub and GDB
would have to support XML register descriptions which is something that
owing to the vast number of CP0 register set variants in the MIPS
architecture has never been implemented. So in fact you may be hitting
problems regardless of the ABI selection noted above.
(gdb) maintenance print registers
command -- see the `Type' column on the right for the internal type used
and note that the registers exchanged with a remote stub are those in the
low half of indices (`Nr' == `Rel'), the so called "raw registers".
HTH,
Maciej
Loading...