EmbDev.net

Forum: ARM programming with GCC/GNU tools How does GDB learn about the CPU's register set?


von Simon (Guest)


Rate this post
useful
not useful
Hi there!

Can anyone tell me how GDB learns about the register set of the CPU it's 
debugging?

I have the following problem: My ARM-Cortex-M3 project works quite fine, 
but GDB shows me the ARM7 register set instead of the Cortex' set:

info reg
r0             0x20004fdc  536891356
r1             0x20004fd8  536891352
r2             0x20000b3c  536873788
r3             0x20000b3c  536873788
r4             0x20000b3c  536873788
r5             0x200000b8  536871096
r6             0x20000cc8  536874184
r7             0x20004fc0  536891328
r8             0x200000b8  536871096
r9             0x20004f8c  536891276
r10            0x20004f8c  536891276
r11            0x20000004  536870916
r12            0x20000ce9  536874217
sp             0x20004fc0  0x20004fc0
lr             0x185  389
pc             0x198  0x198 <main>
fps            0x0  0
cpsr           0x61000000  1627389952



How can I tell GDB that there is a cortex register set?

Best regards
Simon

von (prx) A. K. (prx)


Rate this post
useful
not useful
Where exactly is the difference between ARM and Cortex register set, 
wrt. debugging? It's basically the same. ARM has a SPSR which Cortex 
does not have/use, and this isn't shown.

von Simon (Guest)


Rate this post
useful
not useful
Thank you for your reply!

Are the special registers like primask, control and so on not accessible 
through JTAG?

I've seen a post in this forum about openOCD. There, openOCD seems to 
'see' these registers:

Open On-Chip Debugger
> reg
(0) r0 (/32): 0x2000ffc4 (dirty: 1, valid: 1)
(1) r1 (/32): 0x4001040c (dirty: 0, valid: 1)
(2) r2 (/32): 0x00000000 (dirty: 0, valid: 1)
(3) r3 (/32): 0x00000020 (dirty: 0, valid: 1)
(4) r4 (/32): 0xffffbfef (dirty: 0, valid: 1)
(5) r5 (/32): 0xffbfef00 (dirty: 0, valid: 1)
(6) r6 (/32): 0x4b1ab008 (dirty: 0, valid: 1)
(7) r7 (/32): 0x2000ffa4 (dirty: 0, valid: 1)
(8) r8 (/32): 0xffffffff (dirty: 0, valid: 1)
(9) r9 (/32): 0xf7bfffff (dirty: 0, valid: 1)
(10) r10 (/32): 0xa1a5896d (dirty: 0, valid: 1)
(11) r11 (/32): 0x48fefd6d (dirty: 0, valid: 1)
(12) r12 (/32): 0xfdfdffff (dirty: 0, valid: 1)
(13) sp (/32): 0x2000ffa4 (dirty: 0, valid: 1)
(14) lr (/32): 0x200018df (dirty: 0, valid: 1)
(15) pc (/32): 0x20004ffd (dirty: 1, valid: 1)
(16) xPSR (/32): 0x81000025 (dirty: 0, valid: 1)
(17) msp (/32): 0x2000ffa4 (dirty: 0, valid: 1)
(18) psp (/32): 0x2000a000 (dirty: 0, valid: 1)
(19) primask (/32): 0x00000000 (dirty: 0, valid: 1)
(20) basepri (/32): 0x00000000 (dirty: 0, valid: 1)
(21) faultmask (/32): 0x00000000 (dirty: 0, valid: 1)
(22) control (/32): 0x00000000 (dirty: 0, valid: 1)


So it seems to me that GDB should "see" them as well

von (prx) A. K. (prx)


Rate this post
useful
not useful
I'm no expert in GDB, but I remember that you can pass commands to the 
backend GDB uses as debug interface, so you might be able to use the 
openocd command in GDB.

von Simon (Guest)


Rate this post
useful
not useful
Yes, that's true - using the "monitor" command. But I'm not using 
openOCD, but Segger Jlink-GDBserver. As far as I know, this server 
doesn't know a command to show all registers, but just one at a time - 
using the register name.

And that's making me very curious. When - say - Eclipse wants to show me 
the actual value of the PC, it sends a command to GDB

848-data-evaluate-expression $pc

GDB answers:
848^done,value="0x10c <Reset_Handler>"

Ok. GDB knows that 0x10c is at <Reset_Handler> from the .elf file, I 
guess.

But how does GDB know about a register called $pc? DOES it know about 
that register, or does it just ask the GDB server (openOCD, JLink GDB 
server) about some strange register called $pc, and the GDB server knows 
how to find it?

First, I thought, that the gdbinit file would tell the GDB server about 
the core. But I don't think, it does. All that the GDB server is 
interested in, is, what flash type there is.

von Simon (Guest)


Rate this post
useful
not useful
Hmmmmmmm.....

Maybe, the .elf file also tells some interesting things about the 
core???? After all, the compiler and the linker know what core they are 
dealing with...

Does anyone know how this works?

von NoX (Guest)


Rate this post
useful
not useful
readelf -A

Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.