GDB Improvements for Telecom System

GDBs Strengths, Today Primary debugger for Linux Used by Eclipse for C, C++ debugging –Eclipse communicates with GDB via MI (Machine Interface) protocol Debug multi-threaded programs Supports remote debugging GDB is Open Source

GDBs Limitations, Today When any thread stops, all must stop Can debug only one process at a time No support for telecom OS like DICOS CodeSourcerys work for Ericsson will remove all these limitations under DICOS, and most under Linux

Non-Stop Debugging Mode When one thread stops, others can continue to run GDB reports breakpoint hits, etc. even while waiting for user commands User can stop or run each thread independently Natural behavior for Eclipse debugging

Non-stop Benefits Reduced impact on debuggee Allows inspection of live systems Can synthesize other useful behaviors: –Together with multi-process debugging: Stop all threads in this process, but leave other processes running –Dedicated debugger interaction threads

Multi-Process Debugging GDB can attach to or detach from each process independently GDB can follow both parent and child after a fork Breakpoints can be global to all attached processes

Multi-Process Debugging: Limitations GDB still has only a single address space map For DICOS, this is not a problem, since code and data are global to all processes On Linux, GDB will only handle families of processes with identical address maps: fork, but no exec, no dlopen/dlclose

DICOS Support Connect to DICOS processor via GDBs remote protocol over TCP/IP List processes and capsules, attach and detach GDB can attach automatically to new processes that hit global breakpoints

Additional improvements Optimization Analysis Tracepoints Process-specific breakpoints Linux multi-process debugging