Code::Blocks Forums
User forums => Using Code::Blocks => Topic started by: pooh on May 12, 2012, 07:47:50 pm
-
Hi,
I have manged to build a GNU-cross-toolchain for MIPS under MSYS.
And I am using GDB 7.4 for remote debugging.
But I think my problem is not related to any embedded target ...
I am facing this "simple" problem:
When activating the "CPU registers" debug window it doesn't contain anything.
I have already checked the debuggers log. GDB seems to transmit something useful to C::B
In the debugger log window I get:
> info registers
zero at v0 v1 a0 a1 a2 a3
R0 00000000 00000000 00000001 00000000 00000000 00000000 00000000 00000000
t0 t1 t2 t3 t4 t5 t6 t7
R8 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
s0 s1 s2 s3 s4 s5 s6 s7
R16 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
t8 t9 k0 k1 gp sp s8 ra
R24 00000000 00000000 00000000 00000000 00007170 00017198 00017198 00000000
sr lo hi bad cause pc
00000000 00000000 00000000 00000000 00000009 00000128
fsr fir
00000001 00000001
BTW: Other debug windows work fine (e.g. Examine Memory or Disassembly)
Why doesn't C::B show a copy of the GDB output??? Any idea what's wrong here?
I appreciate any help!
Thanks, guys!
-
Solved:
After digging into the C::B source code, I tried to set the disassembly flavor (Settings->Compiler and Debugger->Debugger Settings) to custom flavor "or32"... And that's it! Now I the registers are shown in the debug window.
-
Patch?
-
Patch?
What patch? It's an option IMHO...?!
-
I though he had modified the code, but as you said there is an option to specify a string...
But if it is a common flavor it will be good to add it.
-
Here is the full story:
1.
There is the option to select or32 (i.e. OpenRisc from opencores.org) in my C::B distribution which is the "normal" 10.05.
So, no need to patch C::B.
(Apparently, or32 has found it's way into the official C::B sources...)
2.
I was a bit too enthusiastic when posting that I solved the issue. Actually, selecting or32 was just a first step in the right direction...
It turned out the C::B was confused by "R0", "R8" etc in front of the register value columns. Moreover, mips-gdb puts out a space at the end of the register value row, which seems to be another cause for a mismatch in the displayed register values (e.g. R1 gets the value of R0 and so on)
I tried (just a quick hack) to patch the code for the debugger DLL of C::B. This failed because C::B wasn't able to load my newly created DLL (didn't dig into details here).
Finally, I decided to patch the gdb source for MIPS.
And now it works with the or32 selection in C::B AND the patched mips-gdb.
Perhaps not the most elegant solution - but it works ;-)