CDI debugger for embedded C/C+


Published on

Eenhancements done in CodeWarrior tools to CDT for a CDI based debugger backend targeting embedded platforms that do require
higher introspection into running application/hosting platform and also a
higher degree of controlling how/if a breakpoint is set.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

CDI debugger for embedded C/C+

  1. 1. Improvements to CDI based CDT debugger targeting embedded platforms <ul><ul><li>Teodor Madan, Freescale Semiconductor, Inc </li></ul></ul><ul><ul><li>[email_address] </li></ul></ul>Presented at Eclipse Summit 2009, Wednesday October 28th, Seminarräume 5
  2. 2. Agenda <ul><li>CDT background </li></ul><ul><li>Eclipse for Embedded C/C++ </li></ul><ul><li>CDI changes for embedded </li></ul><ul><ul><li>Target introspection </li></ul></ul><ul><ul><li>Breakpoints </li></ul></ul><ul><ul><li>Memory space </li></ul></ul><ul><li>Q & A </li></ul>
  3. 3. C/C++ Debugging Interface <ul><li>CDT itself does not contain a debugger for C/C++ code. Just support for adding an external debugger, including gdb is an external debugger. </li></ul><ul><li>CDI (C/C++ Debugging Interface): </li></ul><ul><ul><li>CDT API to connect a custom debugger backend to standard graphical debugging capabilities of CDT. </li></ul></ul><ul><ul><li>Standard CDT debugger model is mostly tailored for common look and feel for C/C++ debuggers. </li></ul></ul><ul><ul><li>CDI backend debugger can be created almost without having any UI code. Usually writing a custom launch configuration type is enough. </li></ul></ul><ul><ul><li>GDB-MI is the reference implementation. </li></ul></ul>
  4. 4. Eclipse C/C++ targeting embedded <ul><li>Eclipse has been embraced by most embedded tools vendors as the common IDE platform </li></ul><ul><li>Eclipse based IDE are targeting a diversity of architectures from low-end 8-bit MCU to high-end multi-core processors </li></ul><ul><li>New problem domain brings new requirements to the original CDT support for debugging </li></ul>
  5. 5. Challenges for Embedded domain <ul><li>An embedded developer needs a higher introspection from target. Not just about application debugged but as well about environment/system where application is executed </li></ul><ul><li>High latency for retrieving data </li></ul><ul><li>Often few debug resources especially for bare-metal debugging </li></ul><ul><li>Often cannot setup all breakpoints especially when debugging in ROM </li></ul><ul><li>Single memory space paradigm for all process addresses no longer applies </li></ul>
  6. 6. Variable Location Information <ul><li>Location is where value of variable resides in target memory/register. </li></ul><ul><li>Important to know where variables are located at one glance </li></ul><ul><li>Creating watch expression for variables often is not handy, and not always possible </li></ul><ul><li>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. </li></ul>
  7. 7. Register Location Information <ul><li>SOC registers are usually memory mapped, i.e. correspond to an address in system memory space. </li></ul><ul><li>Usually have an indirect memory access, a base address plus an offset. Base address is often known only by low-level OS logic. </li></ul><ul><li>Other non-memory mapped addressing exists. E.g. register offset/id in a configuration register. </li></ul>
  8. 8. Disassembly memory rendering <ul><li>Viewing any memory region as a disassembled code </li></ul><ul><li>Not tight to current debug context/process memory space </li></ul><ul><li>CDT 6.0. has the ability to go to any address in Disassembly view. But not enough. </li></ul><ul><li>Allows to view disassembly code in any memory spaces that could be different the process memory space. </li></ul>
  9. 9. Export / Import registers <ul><li>Thousands of registers to be monitored for a complex SOC device </li></ul><ul><li>Need to save SOC state. Information to be further analyzed by dedicated teams. </li></ul><ul><li>Restore complete or partially a previous SOC state. </li></ul><ul><li>You can diff a previously saved state with the current target state. </li></ul><ul><li>Imports registers that changed </li></ul>
  10. 10. One stack frame <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>With a single handy click user can specify to backend to not spend time in creating back chain. </li></ul><ul><li>Later when reached the desired location/moment user can order debugger to create the back chain </li></ul>
  11. 11. Breakpoints <ul><li>Few people realize that a line breakpoint, especially for C++, can actually represent multiple location in process code memory space. </li></ul><ul><li>Examples: </li></ul><ul><ul><li>Inline methods. Same code can be inlined in other functions, possible with a modified generated code due to local optimizations </li></ul></ul><ul><ul><li>Templates. Each template instance is actually a different class/method associated with the same source line. </li></ul></ul><ul><ul><li>Inlined templates. Template methods are usually declared inlined as well. STL as an example. </li></ul></ul><ul><li>Debugging C++ code requires a lot of breakpoints. When breakpoints are limited the user has to choose. </li></ul>
  12. 12. Easier navigation in breakpoints view <ul><li>Breakpoints view is being refactored in eclipse 3.6. to use flexible hierarchy. Will be possible to customize view per debug domain needs. </li></ul><ul><li>Display breakpoint instances with resolved location information </li></ul><ul><li>Display not-resolved breakpoints with detailed error information. </li></ul>
  13. 13. Memory space <ul><li>Usually for application in user domain we do not have to care about memory space. At most data vs code </li></ul><ul><li>Debugging a system involves to present/handle information from different problem domain: </li></ul><ul><ul><li>System memory vs user application memory </li></ul></ul><ul><ul><li>Physical memory vs virtual data memory </li></ul></ul><ul><ul><li>Swapped data vs active data (for overlaid application) </li></ul></ul><ul><ul><li>RAM vs Flash </li></ul></ul><ul><li>Just the context where data is presented is not enough. </li></ul>
  14. 14. <ul><li>Q&A </li></ul><ul><ul><li>Teodor Madan, Freescale Semiconductor, Inc </li></ul></ul><ul><ul><li>[email_address] </li></ul></ul>