Posted on:
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
Posted on:
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.
Posted on:
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
Posted on:
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.
Posted on:
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.
Posted on:
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?
Enable email notification
Enable multi-page view