CDI debugger for embedded C/C+

Improvements to CDI based CDT debugger targeting embedded platforms Teodor Madan, Freescale Semiconductor, Inc [email_address] Presented at Eclipse Summit 2009, Wednesday October 28th, Seminarräume 5

Agenda CDT background Eclipse for Embedded C/C++ CDI changes for embedded Target introspection Breakpoints Memory space Q & A

C/C++ Debugging Interface CDT itself does not contain a debugger for C/C++ code. Just support for adding an external debugger, including gdb is an external debugger. CDI (C/C++ Debugging Interface): CDT API to connect a custom debugger backend to standard graphical debugging capabilities of CDT. Standard CDT debugger model is mostly tailored for common look and feel for C/C++ debuggers. CDI backend debugger can be created almost without having any UI code. Usually writing a custom launch configuration type is enough. GDB-MI is the reference implementation.

Eclipse C/C++ targeting embedded Eclipse has been embraced by most embedded tools vendors as the common IDE platform Eclipse based IDE are targeting a diversity of architectures from low-end 8-bit MCU to high-end multi-core processors New problem domain brings new requirements to the original CDT support for debugging

Challenges for Embedded domain An embedded developer needs a higher introspection from target. Not just about application debugged but as well about environment/system where application is executed High latency for retrieving data Often few debug resources especially for bare-metal debugging Often cannot setup all breakpoints especially when debugging in ROM Single memory space paradigm for all process addresses no longer applies

Variable Location Information Location is where value of variable resides in target memory/register. Important to know where variables are located at one glance Creating watch expression for variables often is not handy, and not always possible Compilers might spill a complex variable in different locations when optimizing: e.g. spilling value over few registers. Part of the structure in memory other in register.

Register Location Information SOC registers are usually memory mapped, i.e. correspond to an address in system memory space. Usually have an indirect memory access, a base address plus an offset. Base address is often known only by low-level OS logic. Other non-memory mapped addressing exists. E.g. register offset/id in a configuration register.

Disassembly memory rendering Viewing any memory region as a disassembled code Not tight to current debug context/process memory space CDT 6.0. has the ability to go to any address in Disassembly view. But not enough. Allows to view disassembly code in any memory spaces that could be different the process memory space.

Export / Import registers Thousands of registers to be monitored for a complex SOC device Need to save SOC state. Information to be further analyzed by dedicated teams. Restore complete or partially a previous SOC state. You can diff a previously saved state with the current target state. Imports registers that changed

One stack frame Often in debug scenarios user does do a series of run/stop/step of the target until reached the desired location/moment. Any improvements in time to handle a thread suspended state is beneficial. For targets with high latencies doing stack unwinding takes time. Even attempt to figure out the caller method takes precious ms when user is even not interested in this info. With a single handy click user can specify to backend to not spend time in creating back chain. Later when reached the desired location/moment user can order debugger to create the back chain

Breakpoints Few people realize that a line breakpoint, especially for C++, can actually represent multiple location in process code memory space. Examples: Inline methods. Same code can be inlined in other functions, possible with a modified generated code due to local optimizations Templates. Each template instance is actually a different class/method associated with the same source line. Inlined templates. Template methods are usually declared inlined as well. STL as an example. Debugging C++ code requires a lot of breakpoints. When breakpoints are limited the user has to choose.

Easier navigation in breakpoints view Breakpoints view is being refactored in eclipse 3.6. to use flexible hierarchy. Will be possible to customize view per debug domain needs. Display breakpoint instances with resolved location information Display not-resolved breakpoints with detailed error information.

Memory space Usually for application in user domain we do not have to care about memory space. At most data vs code Debugging a system involves to present/handle information from different problem domain: System memory vs user application memory Physical memory vs virtual data memory Swapped data vs active data (for overlaid application) RAM vs Flash Just the context where data is presented is not enough.

Q&A Teodor Madan, Freescale Semiconductor, Inc [email_address]

CDI debugger for embedded C/C+

More Related Content

Viewers also liked (20)

Similar to CDI debugger for embedded C/C+ (20)

Recently uploaded (20)

CDI debugger for embedded C/C+