• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 1068 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP432 Stepping with GDB in C++ code build with gcc

Dan Cermak
Intellectual 690 points

Hi,


I have been struggling to get stepping to work with the open source toolchain (GCC + GDB) for the MSP432 with C++. I am using the currently latest version of MSPGCC (1_01_00_01) with the bundled XDS emulation package running under Fedora Linux. I have tried the provided examples from the MSPGCC package and they are working flawlessly (I can use hardware breakpoints & stepping instructions). However when running a program written in C++, I can still use hardware breakpoints but stepping no longer works. GDB produces the following output when using the next command (after loading the program and resetting the CPU):

(gdb) next
Single stepping until exit from function __do_global_dtors_aux,
which has no line number information.
Warning:
Cannot insert breakpoint -7.
Cannot access memory at address 0x7674

With the accompanying output from gdb-agent-console:

FAILED! GTI_SETBP_EX(hpid=0x245df50,addr=0x7674,type=0,count=1,access=0)=ffffffff
(Error -1066 @ 0x7674)
Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory.
(Emulation package 6.0.407.3)

ERROR: set_breakpoint() backend call returned 64

Since this looks like an issue with the code being in Flash and not in SRAM, I am using the same system initialization routine as in the provided C examples, so in theory the Code should be copied from Flash to SRAM. To be precise, I am using the following Reset_Handler():

void Reset_Handler() {
  // Call system initialization routine
  SystemInit();

  // Jump to the main initialization routine.
  _mainCRTStartup();
}

where SystemInit() is a function defined in an extern "C" block, as is the function main().


Thanks in advance for any suggestions,

Dan

  • 0
    TI__Prodigy 595 points

    Hey Dan,

    as the hardware breakpoints are working with your code, I suspect that the GDB agent is trying to use software breakpoints for the single step.

    You could try to the command "set breakpoint auto-hw on" to force the GDB agent to use hardware breakpoints explicitly.

    Please refer to SLAU688 chapter 3.2.2.2.2 GDB Breakpoints for more details.

    Thanks,

    Bob Heilmaier

  • 0 in reply to Bob Heilmaier
    Intellectual 690 points

    Hi Bob,

    I already tried that setting (sorry forgot to mention it), it doesn't change anything. I think I have read somewhere that this setting is the default in gdb.

    I suspect that C++ pulls additional stuff into the binary, as I cannot reuse the compiler flags from the example Makefile, I further need to add -specs=nosys.specs to the link flags, or I get the following bunch of errors:

    /ti/msp432_gcc/arm_compiler/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/libc.a(lib_a-abort.o): In function `abort':
abort.c:(.text.abort+0xa): undefined reference to `_exit'
/ti/msp432_gcc/arm_compiler/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/libc.a(lib_a-exit.o): In function `exit':
exit.c:(.text.exit+0x16): undefined reference to `_exit'
/ti/msp432_gcc/arm_compiler/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'
/ti/msp432_gcc/arm_compiler/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/libc.a(lib_a-signalr.o): In function `_kill_r':
signalr.c:(.text._kill_r+0x10): undefined reference to `_kill'
/ti/msp432_gcc/arm_compiler/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/libc.a(lib_a-signalr.o): In function `_getpid_r':
signalr.c:(.text._getpid_r+0x0): undefined reference to `_getpid'
/ti/msp432_gcc/arm_compiler/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text._write_r+0x12): undefined reference to `_write'
/ti/msp432_gcc/arm_compiler/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/libc.a(lib_a-closer.o): In function `_close_r':
closer.c:(.text._close_r+0xc): undefined reference to `_close'
/ti/msp432_gcc/arm_compiler/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/libc.a(lib_a-fstatr.o): In function `_fstat_r':
fstatr.c:(.text._fstat_r+0x10): undefined reference to `_fstat'
/ti/msp432_gcc/arm_compiler/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/libc.a(lib_a-isattyr.o): In function `_isatty_r':
isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'
/ti/msp432_gcc/arm_compiler/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/libc.a(lib_a-lseekr.o): In function `_lseek_r':
lseekr.c:(.text._lseek_r+0x12): undefined reference to `_lseek'
/ti/msp432_gcc/arm_compiler/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu/libc.a(lib_a-readr.o): In function `_read_r':

    My guess is, that the _mainCRTStartup() function does not move some of the additional C++ stuff into SRAM and then the debugger can no longer find the functions in memory. But it has to be something C++ specific (or I totally messed up the compiler flags), since stepping works with the pure C examples.

  • 0 in reply to Dan Cermak
    Intellectual 690 points

    Hi Bob,

    I have managed to resolve the stepping issue while debugging another problem. Apparently the issue was adding -specs='nosys.specs' to the linker flags, as this pulls in a lot of stuff from newlib (e.g. _malloc, _free) for (unnecessary) destructors of global data structures. I replaced it with -specs='nano.specs' and now stepping works fine, as do hardware breakpoints. I hope this does not break other things, as I would prefer not pulling anything from the C standard library that is intended for operating systems (like kill, exit, write, etc.)

    Is there maybe a full guide how to use C++ with the open source toolchain on the MSP432?

    And do you know what exactly caused this strange stepping problem?


    Cheers,

    Dan

**Attention** This is a public forum