2
\$\begingroup\$

I'm using GDB to debug a program for a Cortex M3. In the functions where the program crashes, when I execute line by line (using n), I eventually get:

(gdb) n 
0x0800f498 in ?? ()

now if I backtrace (using bt) right after I get:

(gdb) bt
#0  0x0800f498 in ?? ()
#1  0xfffffff8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

What exactly do the addresses 0x0800f498 and 0xfffffff8 refer to? How did I arrive there? Would looking at the linker map file help?

Edit: When I do info registers this is what I get:

info registers
r0             0x2001ffe8       537001960
r1             0x0      0
r2             0x0      0
r3             0x7ada53e6       2061128678
r4             0x0      0
r5             0x0      0
r6             0x0      0
r7             0x0      0
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x0      0
sp             0x2001ffb0       0x2001ffb0
lr             0xfffffff9       4294967289
pc             0x800f499        0x800f499
fps            0x0      0
cpsr           0x1000023        16777251
\$\endgroup\$
  • \$\begingroup\$ that's just the return adress as it's on the stack and a helpless debugger not knowing what it refers to. how should we know? but 0xfffffff8 looks weird, mabe the guess "corrupt stack?" is right. \$\endgroup\$ – Stefan Paul Noack Apr 30 '12 at 13:23
  • 3
    \$\begingroup\$ You really need to read the Cortex M3 Specs in ARM ARM for ARMv7-M. LR = 0xFFFFFFF9 is a "magic" value for exception return. \$\endgroup\$ – Turbo J Apr 30 '12 at 13:34
  • \$\begingroup\$ @TurboJ You should make this an answer, so I can vote it up \$\endgroup\$ – Toby Jaffey Apr 30 '12 at 13:51
6
\$\begingroup\$

You have two problems:

  1. Your debugger does not know about ARMv7-M exceptions.
  2. Your code triggers a fault probably due to a programming error, like forgetting to enable a peripherial clock.

In this case the debugger gets confused by the magic 0xFFFFFFFx value in LR. You could try to manually inspect the register values saved on the stack to locate the original PC value.

The address 0x0800f498 might be in the Hard Fault exception handler. I ususally use my own handler with a special LED blinking sequence so I know when things went wrong.

The gdb in Sourcery CodeBench has support for this exception model, but you may need a target.xml file to enable it.

\$\endgroup\$
1
\$\begingroup\$

The hex number is the value of the program counter or stack address (check your manuals), the "??" is the function currently being executed.

If you compile your code with debugging symbols (with gcc you need to use the -g flag) then the debugger should be able to correctly print the function name.

To work it out for yourself, you can either study the map file or use address2line which should be in your GNU ARM toolchain.

\$\endgroup\$
  • \$\begingroup\$ I am debugging with the -g flag. It usually prints the name of the function all nicely, but here - where my program crashes - it gets confused. \$\endgroup\$ – Randomblue Apr 30 '12 at 13:25
  • \$\begingroup\$ Then your program has probably destroyed the stack frame, meaning that you can't debug it. Try to catch the instruction before it fails by single stepping through. Use breakpoints to chop down the search space. \$\endgroup\$ – Toby Jaffey Apr 30 '12 at 13:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.