Debugging "BKPT 0" instruction problem

Asked by John S. Kallal

The following header works in the IAR debugger but not in GDB:

///////////////////////////////////////////////////////////////////////////////
/// @file rom_debug_break.h
/// @brief Debugging help definitions, macros, and code.
///
/// This file should should be included by any code file that uses any
/// macros, external variables, or function defined in this header or
/// matching code file.
///
///////////////////////////////////////////////////////////////////////////////
/******************************************************************************
 * Copyright (c) 2014 John S. Kallal
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without modification,
 * are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice,
 * this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright notice,
 * this list of conditions and the following disclaimer in the documentation
 * and/or other materials provided with the distribution.
 * 3. The name of the author may not be used to endorse or promote products
 * derived from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
 * SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
 * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
 * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
 * OF SUCH DAMAGE.
 *
 * Author: John S. Kallal
 *
 ****************************************************************************/
#ifndef ROM_DEBUG_BREAK_H // Recursive inclusion protection
#define ROM_DEBUG_BREAK_H

#if !defined(__CORTEX_M)
  #warning Maybe missing needed ARM core include file.
#endif

///////////////////////////////////////////////////////////////////////////
/// @brief Debugger halt ROM code macro
///
/// This preprocessor macro causes a debugger halt with an inline
/// "BKPT 0" instruction with the preprocessor symbol
/// \b ROM_DEBUG_BREAK_OFF undefined. With the compiler preprocessor
/// symbol \b ROM_DEBUG_BREAK_OFF defined, this macro will be defined
/// as expanding to a void expression. Because the debugger does not
/// install this macro's halting code sequence, this preprocessor macro
/// does \b not create a debugger breakpoint. Therefore, unlike a
/// debugger breakpoint this macro's debugger halt \b cannot be disabled
/// and enabled in the debugger.
///
/// Often in a embedded software program, there can be many locations
/// where fixed debugger breakpoints would be helpful doing debugging
/// (i.e. error and fault handling code locations). However, a Cortex-M
/// processor's debugger interface provides only a limited number of
/// hardware breakpoints. This macro's inline "BKPT 0" instruction(s)
/// do \b not use any of the hardware breakpoints. Therefore at a
/// PROM bytes and a possible few instruction execution times, this
/// macro helps workaround the processor's debugger interface hardware
/// breakpoint limit while execution from PROM.
///
/// For a Cortex-M0/M0+ processor, the software \b cannot read the
/// Cortex-M DHCSR debug register. Therefore for a Cortex-M0/M0+
/// processor, this macro expands to a plain unconditional inline
/// "BKPT 0" instruction. For a Cortex-M0/M0+ processor when running
/// \b without debugger control a "BKPT 0" instruction will cause a
/// \b HardFault exception. Therefore for a Cortex-M0/M0+ processor
/// and normal (i.e. non-debugging) software execution, the compiling
/// conditions \b should make this macro expand to a void expression
/// and thereby removing the unconditional inline "BKPT 0"
/// instructions from this preprocessor macro.
///
/// For a Cortex-M3/M4 processor, this macro first tests for
/// debugger control from a Cortex-M DHCSR debug register bit.
/// This macro's code only executes the inline "BKPT 0" instruction
/// when under debugger control. This macro's code skips the
/// inline "BKPT 0" instruction when \b not under debugger control.
/// Therefore on a Cortex-M3/M4 when running without a debugger,
/// this macro's inline "BKPT 0" instruction is skipped and can
/// remain for non-debugging program operation. On a Cortex-M3/M4
/// processor, this macro uses around 4 instructions times and
/// 14 PROM bytes for debugger control testing.
///
/// @note On the IAR ARM tool-set, this preprocessor macro works
/// without problems when debugging. The IAR C-SPY debugger skips over
/// this preprocessor macro's embedded "BKPT 0" instruction(s) when
/// continuing program execution. However with the
/// "GNU Tools ARM Embedded 4.8" tool-set under CoIDE v1.7.6 or
/// LPCXpresso v7.1.1_125, there is some problems when debugging. As
/// a workaround, GDB requires a manual "set $pc+=2" command to skip
/// over the program's embedded "BKPT 0" instructions before continuing
/// program execution. The following GDB signal command sequence does
/// \b not work and prints nothing: @verbatim
/// catch signal SIGTRAP
/// command
/// >p "SIGTRAP at"
/// >p/x $pc
/// >if 0xbe00==(*((unsigned short*)($pc)))
/// >set $pc+=2
/// >p "BKPT(0) instuction, program counter increased to"
/// >p/x $pc
/// >end
/// >end
/// @endverbatim
///
/// @todo Either GDB needs to be \b fixed, or a better GDB
/// workaround found and documented.
/// @verbatim
///
/// @return None
///////////////////////////////////////////////////////////////////////////
#if !defined(ROM_DEBUG_BREAK_OFF)
  #if defined(__CORTEX_M) && (3==__CORTEX_M || 4==__CORTEX_M)
    #define ROM_DEBUG_BREAK() \
      do { \
        if ( (CoreDebug->DHCSR)&CoreDebug_DHCSR_C_DEBUGEN_Msk ) \
            __BKPT(0); \
      } while (0)
  #else
    // Assuming a Cortex-M0/M0+ type core.
    // Define the ROM_DEBUG_BREAK() macro as a plain inline "BKPT 0" instruction.
    #warning Embedded BKPT() instruction(s) may ONLY permit debugger execution.
    #define ROM_DEBUG_BREAK() __BKPT(0)
  #endif
#else
  #define ROM_DEBUG_BREAK() ((void)(0))
#endif

#if !defined(__BKPT)
#warning Defining missing __BKPT() instruction. CMSIS version should be upgraded!
///////////////////////////////////////////////////////////////////////////
/// @brief Breakpoint
///
/// The BKPT instruction causes a Cortex-M processor to enter Debug state.
/// Debug tools can use this to investigate system state on reaching a
/// given BKPT instruction.
///
/// @param [in] value has possible debugger meaning but is ignored by the processor.
///////////////////////////////////////////////////////////////////////////
#if defined ( __CC_ARM ) /*------ RealView Compiler -----------------*/
#define __BKPT(value) __breakpoint(value)
#elif defined ( __GNUC__ ) /*------- GNU Compiler ---------------------*/
#define __BKPT(value) __ASM volatile ("bkpt "#value)
#endif
#endif

// End of file, close all open Doxygen groups.
///////////////////////////////////////////////////////////////////////////////
/// @}
///////////////////////////////////////////////////////////////////////////////
#endif /* ROM_DEBUG_BREAK_H */

Question information

Language:
English Edit question
Status:
Answered
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Joey Ye (jinyun-ye) said :
#2

John,

I had a quick try and found that
 catch signal all
works, but has no idea why
 catch signal SIGTRAP
doesn't

Is this workaround acceptable to you?

- Joey

Can you help with this problem?

Provide an answer of your own, or ask John S. Kallal for more information if necessary.

To post a message you must log in.