• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
CDI debugger for embedded C/C+

CDI debugger for embedded C/C+



Eenhancements done in CodeWarrior tools to CDT for a CDI based debugger backend targeting embedded platforms that do require ...

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.



Total Views
Views on SlideShare
Embed Views



3 Embeds 8

http://www.slideshare.net 3
http://www.linkedin.com 3
http://www.lmodules.com 2



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    CDI debugger for embedded C/C+ CDI debugger for embedded C/C+ Presentation Transcript

    • 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]