CDI debugger for embedded C/C+

TM

Freescale™ and the Freescale logo are trademarks of Freescale Semiconductor, Inc. All other product, logo or service names are the property of their respective owners.

Improvements to CDI based CDT debugger targeting embedded platforms

Teodor Madan, Freescale Semiconductor, [email protected]

Presented at Eclipse Summit 2009, Wednesday October 28th, Seminarräume 5

TMFreescale™ and the Freescale logo are trademarks of Freescale Semiconductor, Inc. All other product, logo or service names are the property of their respective owners.

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, [email protected]

Technology

CDI debugger for embedded C/C+