Can I debug a Xilkernel-based design in GDB, and are there caveats?
1. GDB has no kernel awareness. It treats Xilkernel as it does a standalone program. Therefore, it will not provide the type of information (such as indicating explicitly what thread is stopped, what kernel resources are used, scheduler information, etc.) that most kernel debuggers provide.
2. It is still possible to debug user applications on top of Xilkernel. You would see all the threads at the same time, and putting a breakpoint and hitting it will stop all the threads and the kernel.
3. You will also see low-level interrupt handling and kernel code; and if you continue to step long enough after a breakpoint, the debugger might enter the kernel code. You can also insert breakpoints within kernel code and stop it and examine kernel resources or operations. In this respect, you are actually debugging the kernel and not the application per-se.
4. Points 1 to 3 will work only for MicroBlaze and will not work for PowerPC, since GDB/XMD does not support interrupt-driven program debugging on PowerPC.
5. With the call to Xilkernel_main(), control does not come out of this function and interrupts/context switching start here. So it is a particularly "bad" function to try to step into or step past. As such, it is suggested you place your breakpoints in the application threads. You can then hit continue, and GDB should stop directly in the application thread. Once it stops there, you should be able to step/next/finish as usual.
6. Be sure to compile both the user application and the EDK libraries with the -g compiler switch. Xilkernel_main() is within the EDK libraries and unless the -O0 switch is added to the Software Platform settings, code will not step into libraries. For more information, see (Xilinx Answer 22602).
7. Be especially attentive when debugging programs that require user interaction to continue. For example, assume the program implements a command line. A call to receive characters on the uart might block until the user enters the command at the command prompt. As the program is blocking on a call to uart receive, it will appear as if GDB is hanging. In reality, the program is blocked on this call and waiting for user input. Once the user enters the command, GDB will continue.
8. Some complex operations can take some time to complete. To an impatient user, it might appear that GDB is hanging. To avoid this, be sure to include appropriate breakpoints and understand that the code in GDB will not have the same performance as the code running on the board.