• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 1934 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Feature request: __debugbreak() intrinsic for software breakpoints

Robert Cowsill
Guru 16361 points


Many CPUs support an instruction that can be used to halt execution and notify an attached debugger that something happened. Intel x86 has "int 3", MSP430 has opcode 0x4343 and ARM cortex can use "bkpt #0x0", for instance.

These instructions allow debuggers to add breakpoints without consuming hardware resources on the target, but also provide a useful way for code on the target to break into the debugger on error conditions. Trap ISRs and asserts can be made much more powerful if they can actually break in the debugger rather than just entering an infinite loop or sending some text output.

It would be really helpful if the TI compiler provided an intrinsic, similar to __no_operation(), which would emit the appropriate software breakpoint opcode for the target platform (assuming it has one). Does that sound feasible?

  • 0
    TI__Guru**** 251010 points

    Entry SDSCM00018583 had already been filed in the SDOWP system to request this feature.  I added your information to it.  Customer requests like this help to move these issues to a higher priority, and increase the likelihood they get implemented.  

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Guru 16361 points

    Excellent! Thanks George.

  • 0
    Expert 1240 points

    For more information related to setting breakpoints in code, some information is available in the wiki.

    Mr. Cowsill's suggestion for an intrinsic could make this more clean/portable.

  • 0 in reply to user347219
    Guru 16361 points

    Removing the need for conditional compilation to pick the right opcode on multi-platform sourcebases is one of the reasons I suggested this.

    The other is that it precisely specifies a breakpoint opcode for those platforms where the hardware design doesn't actually do so.

    On MSP430, opcode 0x4343 is treated the same as any other NOP as far as the CPU is concerned. It's only the fact that the CCS debugger configures an EEM trigger to fire when an 0x4343 opcode is fetched that makes this the software breakpoint opcode. On other platforms, special significance is given to particular immediate operand values. In cases like this it can be time consuming to figure out how to embed a software breakpoint in source.