Known problems


The single-stepping currently used in gdb-cris is software single-stepping performed on the host side. As a consequence, stepping is not fool-proof. If you try to step past an assembly instruction, and the program just continues until the end of the program (or until next breakpoint) that's a good sign of the single-stepping mechanism failing.

If step or next fails, try setting a breakpoint where you want to stop and then continue to reach the desired point in your program. (If you can isolate the place where single-stepping fails and send us the code we'd be grateful.)

Backtrace in Threads

When backtracing in a thread, gdb is unable to determine that the clone function terminates the call stack:

  #0  thread_function (arg=0x0) at hello.c:7
  #1  0x3556e06a in pthread_start_thread (arg=0x0) at manager.c:262
  #2  0x3556e0b2 in pthread_start_thread_event (arg=0x9f7ffc00) at manager.c:285
  #3  0x3560d244 in clone () from /usr/local/cris/r59/cris-axis-linux-gnu/lib/
  #4  0x3560d244 in clone () from /usr/local/cris/r59/cris-axis-linux-gnu/lib/
  Previous frame identical to this frame (corrupt stack?)

The stack is not corrupt however. The reason is that clone lacks the necessary debug information.

Reporting Bugs

Report bugs to the standard developer mailing list

axis/gdb-known-problems.txt · Last modified: 2007/03/07 13:19 by jesper
All text is available under the terms of the GNU Free Documentation License (see Copyrights for details).